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PERFORM  SUCH  OTHER  FUNCTIONS  OR  TASKS  AS  MAY 
BE  DIRECTED  BY  HIGHER  AUTHORITY. 

NHRC  INSTRUCTION  5450.1  G 
22  MARCH  88 


WELCOME  ABOARD 


CAPTAIN  ROBERT  D.  CHANEY.  MC.  USN 

CAPTAIN  CHANEY:  First,  let  me  introduce  myself.  I  am  Captain  Robert 
Chaney.  I  am  Commanding  Officer  of  the  Naval  Health  Research  Center.  San  Diego. 
On  behalf  of  the  Naval  Medical  Research  and  Development  Command  and  the  Naval 
Health  Research  Center  of  San  Diego,  it  is  my  distinct  privilege  to  welcome  all  of  you  to 
what  I  am  sure  will  be  a  very  creative  and  productive  meeting  on  combat  simulation 
issues. 

This  meeting  today  is  a  component  of  a  Naval  Health  Research  Center  contract  with 
the  Lawrence  Livermore  National  Laboratory.  It  is  designed  to  assist  the  Naval  Medical 
Research  and  Development  Command's  Human  Performance  Modeling  Working  Group 
(headed  up  by  LCDR  Ron  Chrisman),  in  the  identification  of  promising  areas  of  research 
on  human  performance  issues  related  to  combat  simulation  modeling.  Better  say  that 
again.  Human  performance  issues  related  to  combat  simulation  modeling.  That’s  what 
we  are  all  about. 

There  will  not  be  time  for  me  to  introduce  everybody  personally,  but  I  sincerely 
hope  that  you  will  all  get  a  chance  to  know  one  another  so  that  everyone  can  take 
advantage  of  the  enormous  bank  of  expertise  that  we  have  represented  here  today. 

As  I  said,  I  can't  introduce  everybody,  but  I  would  like  to  acknowledge  one  very 
distinguished  guest-that  is  Dr.  Earl  Alluisi.  Dr.  Alluisi  is  the  Assistant  for  Training  and 
Personnel  Technology  for  the  Director  of  Environmental  Life  Sciences  Division,  under 
the  auspices  of  Deputy  for  Research  and  Advanced  Technology  of  the  Undersecretary  of 
Defense  for  Acquisition.  Dr.  Alluisi  we  appreciate  you  taking  time  from  an  obviously 
very  busy  schedule  to  be  with  us  today  and  share  the  expertise  which  you  bring. 

(Response  from  Dr.  Alluisi:  Thank  you,  sir.  Pleased  to  be  here.) 

CAPT  CHANEY:  I  wish  to  acknowledge  the  contributions  of  the  representatives 
from  our  fellow  Navy  labs  who  you  will  hear  more  from  later  on.  In  addition,  we 
want  to  recognize  that  the  success  of  this  meeting  will  be  largely  due  to  the 
contributions  not  only  of  those  from  our  sister  services,  but  also  from  the  various 
corporations  represented  here. 
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I  especially  want  to  wish  a  hearty  welcome  to  our  potential  customers.  The 
ultimate  success  of  this  meeting  is  further  assured  by  the  participation  and  guidance  of 
these  operational  and  end  users.  We  must  be  ever  mindful  of  the  fact  that  any 
development  of  more  accurate  estimates  of  combat  performance  must  be  usable  within 
the  context  of  operational  planning.  So  1  urge  all  the  researchers  present  to  capitalize 
and  exploit,  if  you  will,  the  collective  expertise  of  these  operational  end  users. 

Now  to  the  area  of  simulation  of  combat  performance  and  its  impact  on  the  mission 
of  the  Naval  Health  Research  Center. 

“MISSION.  To  support  fleet  operational  readiness  through  research,  development, 
test  and  evaluation  on  the  biomedical  and  psychological  aspects  of  Navy  and  Marine 
Corps  personnel  health  and  performance,  and  to  perform  such  other  functions  or  tasks 
as  may  be  directed  by  higher  authority.' 

We  take  this  mission  statement  very  seriously.  We  have  one  job  and  that  is  to  help 
the  Sailor  or  Marine  do  his  job  better,  safer  and  more  productively.  This  is  a  fantastic 
challenge,  it  is  an  enormous  opportunity,  and  we  try  very  hard  to  Jive  up  to  what  is 
stated  on  that  mission  statement.  There  are  portions  of  the  effort  and  thrust  that  we  at 
Naval  Health  Research  Center  are  working  on.  in  cooperation  with  other  labs  and  the 
Naval  Medical  R&D  Command. 

Physical  readings  standards-  NHRC  has  for  several  years  been  the  lead  lab  within 
R&D  Command  for  the  development  and  validation  of  physical  readiness  standards  for 
the  Navy.  We  are  continually  updating  these  standards,  and  this  is  an  ongoing  process 
we  are  called  upon  to  revisit  over  and  over  again. 

We  also  continue  to  do  follow-on  research  in  areas  of  performance  enhancement 
through  health  promotion.  Is  thi*  net  in  fact  a  good  place  to  look  at  performance 
modeling? 

Military  task  analysis.  Along  with  the  establishment  of  physical  performance 
standards.  Naval  Health  Research  Center  has  been  actively  involved  in  operational  task 
analysis.  NHRC  recently  provided  a  team  of  researchers  to  go  aboard  ships  of  the  line 
to  observe  and  analyze  the  actual  physical  and  mental  requirements  of  each  sailor  in 
each  job.  This  information  was  then  analyzed  and  returned  to  the  line  Navy  to  be  used 
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in  not  only  the  selection  of  personnel  for  various  jobs,  but  the  training  required  to  help 
these  individuals  to  do  their  job  more  effectively. 

Disease  and  Non-battle  Injury  (DNBI).  This  is  a  very  important  area  of  research. 
NHRC  has  taken  an  active  lead  role  in  the  development  of  Navy/Marine  Corps  specific 
predictive  models  of  disease  and  non-battle  injury,  the  one  question  mark  in  any  combat 
scenario.  This  is  intended  to:  1)  lead  to  more  accurate  estimates  of  casualty  and  injury 
mechanism.  2)  more  accurate  estimates  of  infectious  disease  rates.  3)  the  potential  for 
more  accurate  force  degradation  estimates,  and  4)  the  aiding  of  Navy  and  Marine  Corps 
medical  planners  for  more  accurate  estimates  of  the  quantity  of  supplies,  equipment  and 
medical  personnel  necessary  to  meet  real  world  contingencies. 

gliYsiQlQgical  and  psychQiQgical.de ter mmates  of  combat  performance.  The  purpose 
of  this  area  of  research  is  to  analyze  mechanisms  of  performance  degradation  with  the 
aim  of  providing  the  means  of  enhancing  performance.  Not  only  do  we  find  out  what 
the  problem  is,  we  hopefully  will  be  able  to  submit  some  ideas  of  how  to  fix  some  of 
these  problems. 

Areas  of  particular  emphasis  have  been  sleep  deprivation  and  the  adverse 
psychological  reactions  to  stressful  environments.  A  team  of  NHRC  research 
physiologists  and  psychologists  recently  returned  from  their  second  data  gathering 
deployment  aboard  surface  ships  in  the  hot,  humid  and  extremely  stienful  Arabian 
Gulf.  Our  question  was:  what  is  the  combined  effect  ot  heat,  stress,  sleep  deprivation, 
and  fatigue,  in  an  obviously  hostile,  threatening  envirxmment?  Think  about  the  last  time 
researchers  went  aboard  combat  ships  of  the  line  in  combat  or  near  combat  to  see  the 
effect  on  the  individuals  doing  their  job.  How  can  we  incorporate  this  into  a 
performance  modeling  effort? 

Measurement  of  combat  performance.  The  Naval  Medical  RAD  Command  has 
embarked  on  an  aggressive  research  program  relating  laboratory  based  measures  of 
physical  and  mental  performance  with  field  measurement  of  combat  task  performance. 

While  I  was  in  the  Arabian  Gulf,  I  had  a  chance  to  talk  to  several  of  the  senior 
members  of  the  line  community,  one  of  which  was  an  individual  who  was  involved  in 
the  investigation  of  the  Stark.  As  soon  as  he  found  out  where  I  was  from,  he  said,  "We 
got  to  talk."  He  said  the  one  common  thread  that  went  through  the  investigation  of  the 
persons  who  fought  the  fires  aboard  the  Stark  and  ultimately  saved  the  ship,  was  that 
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the  most  physically  fit  performed  the  best  b\  that  stressful  situation.  Obviously  this  is 
an  area  that  NHRC  and  all  of  the  Medical  Naval  R&D  Command  have  approached  with 
great  vigor. 

NHRC’s  efforts  have  been  focused  on:  1)  performance  during  sustained  cold 
weather  shipboard  operations,  and  2)  Marine  Corps  operation  in  the  arctic  environment. 
This  winter  we  will  go  with  one  battalion  landing  team  of  Marines  from  Camp  Lejeune 
to  the  Marine  Corps  Mountain  Warfare  Training  Center  in  Pickle  Meadows,  California, 
then  to  Wisconsin,  and  finally  on  to  Norway.  We  will  troop  right  along  with  these 
folks  to  find  out  what  their  problems  are,  what  stresses  they  experience,  what 
shortcomings  we  can  help  them  with,  and  hopefully  make  their  job  easier.  One  more 
opportunity  to  work  on  a  performance  modeling  effort. 

We  are  also  involved  with  the  U.  S.  Navy  SEALS  working  in  special  warfare 
operations  in  cold  water.  I  am  talking  about  Adak  and  Norway,  and  other  inviting 
places  of  that  type.  Hey  does  this  individual  do  his  job,  and  how  can  we  help  him?  How 
will  the  overall  effects  of  sleep  deprivation  and  fatigue  affect  performance  during 
sustained  combat  operations  in  a  cold  environment?  How  do  you  incorporate  that  in 
your  combat  simulation  models? 

I  would  like  to  quit  at  this  point  because  there  are  a  great  many  people  here  who 
have  far  more  specific  presentations  for  you  than  what  1  am  giving  you  at  this  point.  I 
think  it  is  obvious  that  the  Naval  Health  Research  Center  and  the  Naval  Medical  R&D 
Command  want  very  much  to  see  what  can  be  done  to  utilize  this  performance  modeling 
effort.  We  appreciate  all  of  your  interest  and  your  presence  here  today. 

I  would  like  to  give  special  recognition  to  Bill  Banks  and  Dennis  Kelleher  and  all 
the  rest  of  the  people  who  helped  put  this  together.  Dennis  and  Bill  Banks  obviously 
have  done  a  super  iob.  and  I  appreciate  what  they  have  done  to  make  this  thing  come 
about. 

Once  again  I  welcome  you  all  here  today.  I  hope  we  have  a  very  productive 
meeting.  Please  talk  to  one  another  and  make  this  a  good  information  exchange. 
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MR.  BANKS:  Thank  you.  Captain  Chaney.  I  would  like  to  first  of  all  welcome  all 
of  you  to  Lawrence  Livermore  National  Laboratory.  I  would  like  you  all  to  know  that 
we  are  very  honored  to  be  able  to  work  closely  with  the  Navy  in  trying  to  forge  this  new 
thrust  area  of  research 

1  would  like  to  introduce  Captain  Tom  Jones  from  the  United  States  Navy  who  will 
discuss  the  overview  of  Navy  modeling  needs-current  and  future. 

CAPTAIN  T.  JONES.  MSC.  USN.  NMRDC 

CAPTAIN  JONES:  Good  morning,  ladies  and  gentlemen.  My  name  is  Tom  Jones,  I 
am  currently  the  Research  Area  Manager  for  Aviation  Medicine  and  Human 
Performance  at  the  Naval  Medical  Research  and  Development  Command  (NMRDC), 
Bethesda.  Maryland.  I  would  like  to  express  my  sincere  appreciation  to  the  organizers 
of  this  conference  on  behalf  of  NMRDC  for  the  invitation  to  talk  to  you  this  morning. 
Captain  Melaragno.  the  Research  Director  at  NMRDC.  asked  me  to  extend  to  you  his 
regrets  for  not  being  able  to  attend  this  morning,  because  he  is  vitally  interested  in  the 
area  of  cognitive  psychology  in  general  as  well  as  in  simulation  and  performance,  which 
is  the  subject  of  today’s  and  tomorrow’s  discussions. 

During  the  trip  yesterday.  I  attempted  to  develop  notions  as  to  how  and  what 
remarks  may  be  appropriate  for  today.  1  decided  10  constrain  my  remarks  to  basically 
the  job  that  I  currently  hold  at  NMRDC.  i.e.,  tfc  se  parameters  that  I  manage  as  part  of 
the  human  performance  program. 

Captain  Chaney  mentioned  several  that  are  currently  ongoing  at  his  laboratory. 
Other  similar  programs  are  being  conducted  at  the  Naval  Aerospace  Medical  Research 
Laboratory  (NAMRL)  at  Pensacola,  and  the  Naval  Medical  Research  Institute  (NMRI)  in 
Bethesda.  Maryland. 

It  would  be  extremely  pretentious  on  my  part  to  assume  that  I  could  articulate 
effectively  Navy  modeling  needs.  It  also  would  be  presumptuous  on  my  part  to  assume 
that  I  would  be  able  to  tell  such  an  esteemed  group  of  technical  experts  in  the  area  of 
modeling  anything  technical  that  they  don’t  already  know.  I  therefore  took  the  liberty 
to  restrict  my  remarks  to  issues  in  modeling  and  human  performance  data  bases.  That 
seemed  to  me  to  be  more  appropriate  in  terms  of  the  program  that  will  follow. 
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As  part  of  our  ongoing  research  program  we  have  incorporated  the  MicroSAINT 
model  into  the  research  efforts  at  the  NMRI.  !t  is  also  being  considered  as  a  modeling 
tool  for  work  ongoing  at  the  Naval  Aerospace  Medical  Research  Laboratory.  Pensacola, 
and  I  think  it  is  also  under  consideration  at  NHRC.  This  MicroSAINT  methodology  will 
primarily  be  used  to  exercise  an  evolving  data  base  of  psychophysiological  data  for  the 
prediction  of  successful  performance  in  sustained  operations  in  both  air.  sea  and  special 
warfare  environments. 

In  the  context  of  scarce  and  reduced  resources,  and  a  continuing  need  for  high 
quality  R&D.  I  think  there  is  adequate  justification  for  the  pooling  of  technical  assets 
such  as  we  see  here  today.  The  issues  that  we  will  address  in  the  next  couple  of  days 
hopefully  will  provide  fundamental  information  that  will  assist  me  in  managing  my 
program  more  effectively,  and  help  me  utilize  my  scarce  resources  in  a  manner  that 
will  get  the  greatest  productivity  for  the  smallest  amount  of  dollars.  I  would  like  to 
state  explicitly  that  I  fully  support  technical  actions  that  are  currently  being  taken  to 
explore  this  technology  thrust  area,  but  I  have  reservations  about  the  success  that  we 
might  find  in  this  particular  technology  area. 

My  introduction  to  the  area  of  modeling  started  about  20  years  ago  at  Naval  Air 
Development  Center  in  Warminster,  Pennsylvania,  when  I  was  introduced  to  the  HOS-1 
system,  and  the  concepts  developed  for  HOS  (Human  Operator  Simulator)  by  Dr. 
Robert  Wherry  Jr. 

The  purpose  for  bringing  that  up  is  I  wanted  to  make  two  points.  Number  one,  one 
of  the  problems  that  was  confronted  in  this  early  work  was  that  the  computer  hardware 
and  the  software  and  architecture  were  in  their  infancy,  and  the  implementation  of  the 
conceptualization  of  HOS  was  made  impossible.  Secondly,  the  human  performance  data 
base  required  to  drive  the  HCS  system  was  not  mature  enough.  I  think  that  both  of 
these  problems  were  the  fundamental  reasons  for  the  slowness  in  the  HOS  system 
evolving.  I  think  HOS  is  now  in  its  fourth  iteration,  and  it’s  under  the  auspices  of  the 
Army  Research  Institute.  The  primary  problems  related  to  the  computer  and  software 
aspect  of  the  program  I  think  have  been  resolved.  But  I  am  still  suspicious  of  the  data 
bases  that  are  necessary  to  drive  the  program.  The  challenge,  therefore,  is  to  effectively 
integrate  modeling  tools,  which  are  highly  sophisticated,  with  the  human  performance 
data  bases  that  are  evolving. 
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The  purpose  of  my  participation  is  to  rearticulate  or  reexpress  some  of  the  basic 
issues  or  concerns  for  successful  incorporation  or  integration  and  use  of  human 
performance  data  into  evolving  models. 

I  would  like  to  address  four  basic  issues  in  the  form  of  questions  that  I  think  it’s 
necessary  for  us  to  keep  in  mind.  I’ll  discuss  each  one  of  these  separately. 

The  first  question  is.  what  is  the  goal  of  the  model?  Second,  how  good  is  the  model? 
Third,  what  is  the  data  base  for  the  model?  And  fourth,  what  is  the  process  that  will 
result  in  the  Fleet  using  the  product? 

Now,  let's  return  to  each  one  of  these  questions  separately.  I  won't  go  into  these 
things  in  depth,  but  just  give  you  a  flavor  of  each  of  the  topics  and  the  concern  that  I 
think  that  we  need  to  bear  in  mind  as  we  press  forward  on  this  program. 

First,  what  is  the  goal  of  the  modeling  effort?  What  I  would  like  to  stress  is  the 
implication  that  somebody  has  to  express  what  they  want  to  use  the  model  for,  which 
brings  up  the  question  of  the  user  in  the  fleet  that  Captain  Chaney  mentioned  in  his 
discussion  earlier.  I  think  that  one  of  the  fundamental  difficulties  that  we  have  in 
effectively  introducing  such  technology  areas  into  the  fleet  is  that  we  hold  off  too  long 
in  our  efforts  to  actively  involve  Fleet  participants  in  the  design  process.  If  the  Fleet 
has  a  particular  requirement  that  they  need  new  technology  to  address,  then  it  behooves 
us  to  clearly  understand  the  nature  of  that  requirement,  so  that  we  can  tailor  the 
evolving  technology  to  meet  the  requirement. 

Let’s  take  an  example  of  a  flight  commander  who  has  a  need  for  answering  a 
question  such  as:  what  kind  and  what  amount  of  nonpharmacological  enhancements  will 
he  need  in  order  to  sustain  his  troops  to  effectively  perform  a  particular  on-site 
function?  By  knowing  fundamentally  what  his  question  is,  and  by  knowing  the  other 
related  questions  that  should  be  asked,  we  are  in  a  much  better  position  to  know  how  to 
go  about  the  process  of  designing  the  technology.  The  bottom  line  issue  is  that  we  should 
not  forget  that  the  user  is  an  asset  to  us  in  the  evolving  development  of  new  technology. 
If  we  are  here  to  do  things  for  the  fleet,  than  perhaps  we  should  be  talking  to  the  fleet 
at  an  early  stage  of  technology  development. 
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The  second  issue  is:  how  good  is  the  model?  There  are  four  criteria  that  I  want  to 
bring  up  related  to  this  particular  question.  Most  of  these  things  you  have  heard 
before,  but  1  think  it’s  necessary  that  we  reiterate  them,  because  the  fundamental 
aspects  of  research  are  oftentimes  neglected.  If  they  are  neglected,  it  leads  to 
difficulties  as  we  move  through  the  process  of  trying  to  bring  these  technologies  to  the 
point  that  they  can  be  effectively  utilized. 

The  first  criteria  is  trust.  If  a  user  of  a  modeling  system  asks  a  question,  and 
an  answer  is  provided  or  a  response  provided  by  the  system,  and  that  user  has 
no  understanding  of  the  algorithms  and  how  the  algorithms  are  used  to  evolve 
or  produce  that  answer,  it’s  distasteful  to  them.  This  particular  criteria  has 
evolved  out  of  some  work  that  was  done  at  NADC  on  Expert  Systems.  Trust  is 
a  dimension  I  think  that  is  overlooked  in  terms  of  the  goodness  of  the  model. 

Ihs  second  criteria  ,ia  acceptability-  a  critical  issue  that  is  very  important  from 
a  user  standpoint  in  terms  of  accepting  a  model  is  whether  or  not  the  user  is 
better  off  by  using  the  technology  as  compared  to  the  previous  system  that  he 
is  replacing.  Does  it  save  time?  Is  it  accurate?  Both  the  trust  and  the 
acceptability  dimensions  are  direct  functions  of  effective  interaction  with  the 
user  community. 

The  third  criteria  under  goodness  of  the  model  is  assumptions.  It  is  imperative 
that  we  clearly  define  and  make  explicit  what  the  advantages  and 
disadvantages  of  the  model  are,  and  more  importantly,  understand  the  data 
bases  that  are  driving  the  model.  A  simple  example  that  you  are  probably  all 
aware  of  relates  to  the  general  use  of  linear  regression  for  treating  data  within 
the  context  of  a  model.  However,  the  human  performance  data  bases  that  are 
available  clearly  indicate  that  the  data  are  not  necessarily  linear. 


For  instance,  the  inverted  U  shape  curve  clearly  shows  that  as  stress  increases 
initially  there  is  an  increase  in  performance,  it  flattens  out,  and  then  as  stress 
continues  to  increase,  there  is  a  falling  off.  To  use  a  linear  model  to  predict 
that  sort  of  performance  seems  inappropriate.  This  is  an  issue  that  we  should 
be  sensitive  to. 
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Another  example  of  the  complexity  of  the  human  performance  data  bases  is 
found  in  simple  psychomotor  tasks.  Stress  facilitates  performance  and  results 
in  faster  reaction  times.  For  complex  tasks  better  performance  is  found  in  the 
absence  of  stress.  So  the  assumptions  that  we  make  relative  to  vhe  use  of  the 
model,  as  well  as  the  assumptions  that  we  make  relative  to  the  data  bases  that 
are  feeding  into  the  model  we  use  for  the  predictions,  are  issues  that  we  as 
technologists  should  always  keep  in  mind. 

The  last  criteria  under  model  goodness  is  the  concept  of  validity.  Most  of  you 
know  what  I  am  talking  about.  I  am  not  going  to  go  into  that  to  any  extent, 
other  than  to  say  that  fundamentally  what  we  are  talking  about  when  we  use 
the  word  validity,  it  is  how  well  the  model  does  what  it’s  supposed  to  do.  It  is 
the  link  with  reality.  It  establishes  the  credibility  of  the  instrument  for  the 
purpose  that  the  instrument  was  designed  for. 

As  most  of  you  well  know,  this  is  an  extremely  complicated  and  difficult  issue, 
particularly  when  you  consider  predictive  validity  (trying  to  predict 
operational  performance),  because  of  the  tremendous  variability  that  is  found 
in  operational  environments.  It’s  difficult  to  sort  out  and  refine  techniques 
that  will  clearly  indicate  what  a  particular  model  is  doing,  or  effectively  assess 
whether  a  model  is  doing  what  it’s  supposed  to  do. 

The  third  major  topic  to  be  addressed  is:  what  data  bases  are  used  for  the  model? 
There  are  several  kinds  of  data  that  we  can  address,  but  I  am  going  to  focus  explicitly  on 
the  empirical  data  bases,  because  most  of  the  laboratories  that  are  currently  working  in 
the  advance  program  for  Naval  Medical  Research  and  Development  Command  arc  doing 
empirical  studies  either  using  regression  analyses  to  tie  the  independent  and  dependent 
variables  together,  or  doing  analytical  studies  to  evaluate  relationships  between 
independent  and  dependent  variable.  Two  issues  that  I  want  to  bring  up  related  to  the 
data  base  question  are:  (1)  fragmented  studies,  and  (2)  the  issue  of  generalization. 

What  I  mean  by  fragmented  studies  is  that  you  can  develop  or  design  studies 
that  are  addressing  questions  in  the  same  area.  For  instance,  we  are  asking 
questions  about  the  effect  of  physical  fitness  on  G  tolerance.  One  study  may 
have  one  fitness  regime  and  one  criteria  for  the  effects  of  G  tolerances,  e.g., 
contrast  sensitivity,  visual  contrast  sensitivity  or  peripheral  vision. 
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If  we  try  to  assemble  a  family  of  studies  that  put  together  different 
independent  variables  against  different  dependent  variables,  e.g.,  peripheral 
vision,  contrast  sensitivity,  there  is  a  problem.  It  is  extremely  difficult  to 
combine  studies  together  in  a  composite  data  base  in  a  way  that  will  provide 
the  data  needed  for  the  modeling  effort.  The  bottom  line  related  to  the  data 
base  issue  is  that  we  have  to  strive  to  develop  appropriate  data  bases  with  a 
clear  view  of  model  requirements  and  model  analytic  techniques. 

The  fourth  major  question  is,  what  is  the  process  that  will  lead  to  fleet  use?  The 
linkage  has  at  least  four  fundamental  components:  (1)  a  requirement;  (2)  a  user;  (3)  a 
technology  base/development;  and  (4)  a  transition  system.  I  bring  this  last  one  up 
because  I  think  it  is  imperative  that  principal  investigators  be  aware  of  and  understand 
the  components  essential  for  getting  their  products,  whatever  they  are,  from  point  A  or 
B  to  the  Fleet. 

The  concept  of  requirements  is  really  handled  loosely  in  the  context  of  R&D  in  my 
view.  Basically,  documentation  is  set  forth  and  signed  by  somebody  saying  :hat  research 
needs  to  be  done  for  a  particular  platform,  but  it  doesn’t  specify  clearly  what  needs  to 
be  done  and  who  is  going  to  use  it.  I  continue  to  come  back  to  the  user  because  I  think 
it  is  key  to  effective  use  of  the  concept  and  the  structure  that  we  have  set  forth  for  our 
research  requirements  development. 

If  we  have  only  a  requirement  and  have  not  clearly  identified  the  user  and  what  he 
needs,  what  we  may  find  ourselves  in  is  a  technology  swirl  where  we  go  from  6.1  type 
funding  to  6.2,  to  63,  back  to  6.2,  and  back  to  6.3.  There  is  no  way  out  of  the  box. 

It’s  a  complicated  issue,  but  again  an  issue  that  the  program  managers  as  well  as 
principal  investigators  need  to  keep  clearly  in  mind,  because  they  are  mechanisms  by 
which  technology  can  transfer  directly  from  6.1  in  some  instances  to  6.4,  or  6 2  to  6.4,  or 
it  may  transfer  directly  to  industry.  There  are  mechanisms.  We  need  to  maintain 
awareness  of  them. 

So  in  summary,  the  four  basic  issues  that  I  have  tried  to  emphasize  that  I  think  are 
important  for  us  all  to  keep  in  mind  are:  (1)  what  is  the  goal  of  the  model,  (2)  how  good 
is  the  model  and  the  related  criteria  for  that,  (3)  what  are  the  data  bases  for  the  model, 
and  (4)  what  is  the  process  that  will  lead  to  successful  fleet  use.  If  product  transition  is 
the  goal  (and  it  should  be),  then  the  user  should  be  involved. 
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For  years,  human  factors  professionals  in  the  systems  acquisition  process  indicated 
to  people,  when  they  came  to  them  with  a  problem  in  an  aircraft  system  that  was 
Identified  during  testing  and  evaluation.  "If  you  had  come  to  me  during  the  design 
phase,  you  wouldn’t  have  this  problem  now.  Now  I  can’t  fix  it,  all  I  can  do  is  document 
it." 


Why  should  we  not  look  at  research  and  development  the  same  way.  i.e.,  bring  the 
user  in  at  the  front  end  of  the  thing  as  we  go  through  the  process  of  iteration,  and  we’ll 
have  a  product  that’s  smoothed  out  and  it  is  transitional.  User  involvement  allows  for 
trade-offs  between  the  user  input  notion,  the  model  fidelity  and  the  data  base  issue. 
The  health  of  those  trade-offs  will  smooth  the  way  for  technology  transfer  and  improve 
productivity  and  research. 

Now,  I  haven't  told  you  anything  that  you  didn’t  already  know.  But  what  I  have 
told  you  is  that  basics  in  research  lead  to  quality  research  and  I  am  interested  in  quality 
research.  The  transition  system  is  complicated,  but  with  hard  work  and  determination  it 
is  approachable  and  can  be  utilized.  Modeling  technology  integration  with  human 
performance  data  bases  is  really  the  key  that  we  have  to  keep  in  mind  as  we  approach 
this  subject.  Lastly,  human  performance  modeling  is  an  important  technology  thrust  for 
the  Naval  Medical  Research  and  Development  Program. 

I  thank  you  very  much  for  your  time.  I  am  looking  forward  to  hearing  the 
briefings  to  follow,  and  to  participation  in  the  discussions. 

Thank  you. 
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THOMAS  BERGHAGE.  CDR  MSC  USN  (Ret.):  Thank  you.  Captain  Jones.  My 
name  is  Tom  Berghage,  and  I’ll  be  standing  in  for  Bill  Banks  for  a  few  moments. 

Our  next  speaker  has  been  in  the  forefront  in  the  modeling  effort  in  the  Navy  for 
several  years.  He  has  had  first  hand  experience  with  the  problems  associated  with 
incorporating  human  factors  information  into  a  simulation  model.  This  experience  has 
given  him  some  valuable  insights  into  the  problem.  Without  any  further  ado,  I  would 
like  to  introduce  to  you  LCDR  Dennis  Kelleher. 

ADDRESS  BY  LCDR  DENNIS  KELLEHER,  MSC.  USN 

LCDR  KELLEHER  Thank  you.  I  first  got  involved  in  this  business  back  when  I 
was  at  the  Defense  Nuclear  Agency,  where  we  worked  on  a  program  that  was  looking  at 
the  issues  of  how  do  you  go  about  trying  to  deal  with  data  bases  that  are  incomplete. 
You  have  an  identified  requirement  from  an  end  user  to  come  up  with  predictors  of 
performance,  and  the  available  data  bases  are  incomplete.  You  will  hear  some  of  that 
during  the  presentations  today. 

To  clarify  why  you  were  invited  here,  it’s  easiest  to  go  ahead  and  display  the 
Statement  of  Work  that  we  negotiated  with  Lawrence  Livermore  National  Laboratory, 
so  you  can  see  the  elements  of  what  were  requested  of  Livermore,  and  basically  what  we 
at  NMRDC  expect  to  get  out  of  this  meeting. 

The  two  products  that  you  received  this  morning  are  the  first  deliverables  on  the 
contract.  The  products  are:  (1)  "Review  and  Analysis  of  the  Literature  in  the  Area  of 
Human  Performance  Modeling."  and  (2)  "An  Inventory  of  Wargaming  Models  for 
Special  Warfare:  Candidate  Applications  for  the  Infusion  of  Human  Performance 
Data." 

The  second  contract  requirement  is  to  host  this  meeting  to  not  only  increase  the 
awareness  within  NMRDC  of  combat  performance  and  related  issues,  but  maybe  to  get 
some  continuing  momentum  back  into  the  effort.  As  it  turns  out  I  think  we  got  a  flier 
(as  most  of  you  did)  that  the  Military  Operational  Research  Society  (MORS)  is  going  to 
follow-up  with  another  meeting  in  February  where,  if  you  read  our  Statement  of  Work 
and  their  announcement,  you  would  think  they  were  the  same  thing. 
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The  last  contract  requirement  for  Livermore  is  to  provide  assistance,  hopefully 
along  with  all  of  you.  in  refining  the  technical  requirements  for  NMRDC’s  further 
efforts  in  combat  simulation  modeling  and  human  performance  modeling  areas.  It’s 
been  an  area  that  certain  components  of  the  Navy  have  been  actively  involved  in  for 
many  years,  but  we  want  to  take  a  much  broader  view  of  how  we  can  take  our  data 
bases  and  our  expertise  and  export  them  to  the  Fleet  and  the  Marine  Corps. 

There  are  some  specific  meeting  objectives,  the  first  being  an  enhanced  awareness 
within  NMRDC  of  human  performance  issues  related  to  combat  simulation  modeling. 
We  also  want  to  meet  everybody  and  develop  the  necessary  working  relationships  that 
go  on  within  the  community  of  modelers.  It’s  an  area  that  most  of  us  have  not  had 
much  background  in  and  we  want  to  enhance  and  broaden  our  knowledge  of  computer 
modeling  by  building  a  professional  network.  The  final  objective  is  the  technical 
requirements  development.  That  is,  to  refine  and  report  general  sense,  and  to  a  certain 
extent  a  lot  more  specific  3ense  on  how  we,  at  NHRC  specifically  (and  NMRDC),  can 
make  the  models  work  better.  When  I  say  the  models  I  mean  the  models  that  could  be 
under  development,  along  with  the  models  that  already  exist. 

Today  we  are  going  to  look  at  an  overview,  just  a  very  basic  overview  of  models 
that  already  exist,  models  that  we  selected  for  presentation  at  this  meeting  based  on 
selected  criterion.  The  first  criterion  basically  is  that  these  are  models  that  have  Navy 
utility.  The  types  of  models  that  will  be  presented  today  run  the  whole  spectrum  of 
existing  concepts  of  combat  simulation  models  within  the  Department  of  Defense. 

For  Combat  modeling,  you  will  hear  a  presentation  on  Janus,  of  a,  combat 
simulation  model.  The  reason  you  are  going  to  see  Janus  is  because  some  of  the  data 
from  the  Intermediate  Dose  Program  (ITMED)  has  now  been  put  on  Janus,  and  you 
will  see  that  human  performance  decrement  issues  might  necessarily  turn  an 
engagement  that  used  to  be  a  win  into  a  loss.  So  you  will  see  that  there  is  the  real 
requirement  to  begin  to  import  human  performance  degradation  issues  directly  into 
combat  simulation  models. 

The  second  model  you  will  see  a  presentation  on  is  the  SEES  model,  which  is  also  a 
Lawrence  Livermore  product.  It’s  a  small  unit  force  on  force  engagement  model,  an 
infantry  type  engagement,  that  has  the  capability  of  being  constructed  for  urban 
terrain,  and/or  plain  old  operational  terrain.  The  operations  can  consist  of  units  of  as 
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TECHNICAL  REQUIREMENTS  FOR  FURTHER  RESEARCH 
RELATED  TO  COMBAT  PERFORMANCE  MODELING 


little  as  one  man  all  the  way  up  to  a  company  size  force,  and  can  import  directly  human 
performance  information. 

The  third  model  you  will  see  presented  is  the  TWSEAS  model,  which  is  the  Marine 
Corps’  command  and  control  exercise  mor  1.  It’s  routinely  run  at  Camp  Pendleton. 
Camp  Lejeune,  Quantico.  and  is  now  going  to  be  run  at  Okinawa  as  well.  This  particular 
model  is  currently  undergoing  revision,  and  is  being  changed  to  import  a  module  that 
will  accept  human  performance  decrement  information. 

There  are  also  resource  allocation  models,  if  you  will;  that  is,  models  that  look  at 
division  level  and  Army  level  engagements  to  see  how  you  would  move  forces  about  the 
battle  field  to  take  optimal  advantage  of  a  situation.  These  models  also  can  directly 
import  human  performance  information.  The  model  that  you  will  see  presented  is  the 
AURA  model  from  the  Army’s  Ballistic  Research  Laboratory  (ABRL). 

We  also  have  weapon  effects  models;  the  classical  old  models  of,  given  a  level  of 
weapon  effect,  what  do  you  expect  to  be  the  result  both  in  terms  of  physical  damage, 
and  now  also  in  terms  of  people  damaged. 

The  modelers  from  David  Taylor  Research  and  Development  Center  (DTRDC)  will 
present  the  SHIPDAM  model,  which  tiaditionally  was  viewed  as  just  a  hardware 
damage  rvxiel.  but  now  more  recently  has  been  used  in  an  attempt  to  predict  shipboard 
casualty  production. 

As  one  looks  at  all  of  these  models,  the  first  approximation  has  always  been  casualty 
production,  because  casualty  production  is  the  ultimate  performance  or  force  degrader. 
However,  it's  also  necessary  to  view  factors  other  than  total  casualty  that  can  degrade  a 
combat  force.  Degraded  combat  performance  can  be  caused  by  a  number  of  factors. 
How  does  one  decide  what’s  going  to  be  the  characteristics  of  force  degradation  when 
you  have  less  than  total  destruction  of  force  capability?  Weapons  effect  models 
unfortunately,  until  the  recent  introduction  of  the  intermediate  dose  parameter,  didn’t 
really  have  a  mechanism  for  looking  at  less  than  casualty  produced  performance  steps. 


Tomorrow  morning  we’ll  break  up  into  working  groups  in  which  we  will  identify  a 
couple  of  soecific  areas  that  we  would  like  to  look  at.  One  of  the  four  working  groups 
will  be  on  model  input/dar.  chi  racteristics:  Do  we  have  enough  data  already?  (could  be 
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a  very  real  question).  Do  we  need  to  continue  to  generate  at-the-bench  data,  or  do  w*; 
not  have  a  good  enough  handle  on  the  data  bases  that  already  exist?  Would  we  be 
better  off  by  just  marshalling  the  data  bases  that  currently  exist? 

The  second  working  group  will  be  addressing  the  issue  of  what  are  the  model 
output  requirements.  Output  requirements  to  the  end  user  mean  a  variety  of  things 
depending  on  whether  you  consider  yourself  an  end  user  or  not.  Certainly  the 
operational  forces  are  an  identified  end  user.  I.  however,  identify  myself  as  an  end  user 
and  I  am  just  a  physiologist.  The  reason  I  identify  myself  as  an  end  user  is  that  models 
will  help  me  do  better  research.  If  I  can  get  a  handle  on  which  factor  degrades 
performance,  that  should  help  me  define  a  relevant  experiment  to  look  at  performance 
enhancement.  Models  can  also  help  the  program  manager  prioritize  his  efforts,  because 
he  could  look  at  those  areas  that  would  be  the  most  promising  for  further 
experimentation.  So  the  end  user  is  not  just  a  fleet  operator.  He  is  anybody  who  could 
usefully  use  the  model  to  define  requirements,  to  define  research  areas  of  interest,  and 
to  allocate  necessary  resources. 

The  third  working  group  will  deal  with  transfer  functions.  The  model  transfer 
functions  are  actually  some  of  the  problems  that  have  traditionally  been  dealt  with  »n 
human  performance  modeling,  that  is,  how  do  you  turn  something  like  physical 
performance  data  into  an  estimate  of  combat  performance?  The  transfer  function  for 
using  raw  physiological  data  or  raw  psychological  data  as  a  determinate  of  combat 
performance  has  been  a  real  problem.  These  are  the  black  box  functions  of  how  you  go 
about  extracting  useful  information  from  the  data  bases. 

The  last  working  group  will  be  one  which  will  address  the  issues  of  model 
validation;  that  is,  what  does  it  really  mean  to  have  a  validated  model?  Beyond  the 
obvious  answer  that  if  the  end  user  says  it’s  good  enough,  then  it’s  good  enough,  well, 
that  may  not  be  the  case.  So  we  want  to  have  a  more  precise  definition  of  what  is 
meant  by  model  validation. 

Now,  whose  model  is  it  and  are  we  building  a  new  model?  Maybe  not.  We  are  not 
starting  with  a  preconceived  notion  that  we  are  out  to  build  a  new  model.  As  I  have 
said,  you  are  going  to  have  presentations  today  on  models  that  already  exist,  and  are 
already  being  used  by  the  operator  to  define  requirements.  It  might  be' that  the  only 
requirement  coming  out  of  this  meeting  is  to  tell  the  Navy  to  do  a  better  job  of  looking 
at  the  data  so  that  you  can  give  us  better  estimates  of  performance  decrement  so  we  can 
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use  our  models  better.  We  are  perfectly  willing  to  accept  that  the  Navy  doesn't  need  to 
be  told  to  go  out  and  build  a  new  human  performance  model,  and  that’s  why  we  are 
going  to  see  the  variety  of  models  as  they  exist  today.  Keep  in  mind  that  we  need  to 
view  the  whole  spectrum  of  performance  degrading  factors. 

When  we  look  at  a  model,  we  should  look  at  a  model  as  a  true  estimate  of  combat 
simulation.  We  should  look  at  the  full  spectrum  of  the  factors  that  will  degrade 
performance  in  combat.  They  should  go  all  the  way  from  weapons  effects  down  to 
adverse  psychological  reactions.  That  is  a  big  task  and  it’s  not  necessary  that  the  whole 
pie  be  baked  in  the  oven  at  the  same  time.  It  might  be  very  possible  that  we  could  be 
talking  about  module  production  so  that  he  could  look  at  importing  models  of 
performance  decrement  into  models  as  they  now  exist. 

It  used  to  be  thought  that  these  questions  are  too  big.  We  can’t  do  anything  about 
them.  Well,  with  modularity  we  have  the  option  of  breaking  these  questions  down  into 
smaller  workable  pieces.  Something  to  think  about  in  our  working  groups. 

The  factors  shown  in  this  figure  are  the  ones  in  which  the  Navy/Marine  Corps  have 
traditionally  been  most  interested. 

My  particular  interest  is  the  effects  of  cold.  I  will  be  deployed  with  the  Marines 
this  winter  to  find  out  why  Marines  perform  less  well  in  the  cold  than  they  do  in  heat. 

You  will  see  this  figure  tomorrow  in  the  working  groups,  but  I  would  like  to 
present  it  today  so  that  as  you  see  the  presentations  today  you  can  be  developing 
thoughts  within  your  own  mind  about  what  you  are  going  to  say  tomorrow  in  the 
working  groups.  These  are  the  questions  that  maybe  won’t  be  answered,  but  certainly 
are  the  types  of  questions  that  we  should  be  thinking  about  in  coming  up  with 
conceptual  approaches  to  modeling  efforts. 

Are  there  identifiable  limits  to  what  we  really  can  do  in  modeling?  Should  we  go 
ahead  and  say  yes.  it  would  be  nice  to  have  a  complete  total  concept  of  what  a  Marine 
Corps  division  is  going  to  do  if  you  put  them  in  Norway  with  -23*.  It  would  be  n  ce  to 
be  able  to  tell  the  Marine  Corps  that  that’s  simply  going  to  be  an  impossible  task.  Where 
along  that  spectrum  of  knowledge  should  we  limit  our  efforts,  and  are  there  identifiable 
limits  with  respect  to  input,  output,  model  transfer  functions,  and  validations?  Model 
validation  becomes  a  very  difficult  proposition  when  dealing  with  nuclear  weapons 
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effects.  You  do  not  go  out  and  irradiate  troops  to  find  out  whether  your  model  is  valid 
or  not.  So  we  had  to  come  up  with  a  convoluted  way  to  validate  that  model.  The  same 
would  hold  true  for  a  lot  of  models. 

Are  there  constraints  to  progress  in  this  area?  We  no  longer  think  there  are 
hardware-software  constraints  to  modeling,  whereas  20  years  ago  there  were.  Are  there 
still  data  constraints?  This  is  a  very  real  question.  Do  we  have  enough  data  already? 
The  nice  thing  about  building  models  is  they  can  identify  those  areas  where  you  don’t 
have  enough  data.  So  it.  allows  you.  to  prioritize  your  research  efforts  for  subsequent- 
work. 

Is  there  commonality  among  organizations  in  how  they  use  models?  Is  there 
commonality  in  how  the  Marine  Corps  conceives  of  using  a  model,  how  the  Navy 
conceives  of  using  a  model,  how  the  Air  Force  uses  them,  and  how  the  Army  uses  them? 
Can  we  exploit  that  commonality?  Are  there  operational  and  methodological 
considerations  within  that  commonality  that  will  allow  us  to  share  the  information? 

Are  there  identifiable  essential  elements  as  Captain  Jones  suggested?  If  there  are, 
we  should  have  those  clearly  identified.  Hardware  essential  elements  or  software 
essential  elements,  or  weapon  system  considerations  all  need  tc  be  taken  into 
consideration. 

Again,  the  four  areas  of  interest  are  input,  output,  transfer  functions  and 
validation.  Your  guidance  with  regard  to  these  four  areas  will  help  the  R&D  Command 
develop  technical  requirements  for  modeling.  You  can  also  help  them  develop  a  time 
and  resource  allocation  plan.  We  should  also  be  making  a  list  of  products  that  we  feel 
can  be  developed  for  end  users.  The  agenda  I  have  just  laid  out  is  very  aggressive  and 
we  may  not  be  able  to  accomplish  it  all,  but  we  will  have  taken  the  first  step  in  our 
attempt  to  coordinate  efforts. 

For  the  rest  of  the  day  we  want  to  go  through  a  review  of  a  selection  of  existing 
combat  simulation  models,  not  to  show  any  prejudice  whatsoever  as  to  the  consideration 
of  these  models,  but  to  give  a  flavor  of  the  full  spectrum  of  combat  simulation  models 
from  weapons  effects  through  theater/strategic  decision  making  models. 
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*  ARE  THERE  IDENTIFIABLE  ESSENTIAL  ELEMENTS 

*  WHAT  SHOULD  BE  REASONABLE:  EXPECTATIONS 

**  TIME? 

**  RESOURCES  ? 


Conflict  Simulation  Laboratory  Lawrence  Livermore  National  Laboratory 


Janus  Is  A  Two  Sided  Interactive  Land 
Combat  Simulation  System  That  Supports: 
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CDR  BERGHAGE:  The  first  model  we  are  going  to  hear  about  this  morning  is  the 
granddaddy  of  them  all,  the  Janus  model  which  was  developed  here  at  Lawrence 
Livermore.  And  to  tell  us  about  that  model  will  be  Dr.  Toms  and  George  Anno. 

ADDRESS  BY  DR.  RALPH  M.  TOMS 

DR.  TOMS:  Good  morning.  There  are  some  misconceptions  we  need  to  take  care 
of.  One  is  that  Janus  is  not  an  acronym.  Janus  was  a  Roman  god  who  had  two  views  of 
the  world,  one  red  and  one  blue.  So  parameters  notwithstanding,  it’s  a  good  idea  if  you 
don’t  capitalize  Janus.  Janus  though,  is  a  combat  simulation  system,  not  a  model. 
That's  important.  I  am  going  to  emphasize  that  overall. 

Captain  Jones  talked  about  four  items  that  made  a  model  good.  One  of  them  was 
openness  that  you  publish  within  the  model.  We  are  a  research  center;  you  can  get  all 
the  documentation  of  Janus.  The  algorithms,  documents,  and  user  manual  are  all  public 
property. 

During  this  presentation  I  will  show  you  a  date  log  list  of  the  users  including  the 
Navy.  We  document  our  limitations  as  well  as  our  strengths.  I  have  even  got  a  chart  in 
the  presentation  which  talks  about  our  limitations,  which  are  mostly  in  the  arena  of 
human  factors  which  we  don’t  model.  We  currently  have  an  effort  going  on  right  now 
to  validate  Janus. 

Also  I  want  to  say  one  other  thing  before  I  go  on  with  this  presentation.  In  the 
up-to-date  catalog  of  models  that  you  received,  the  description  of  Janus  is  out-of-date. 
Janus  was  built  by  the  Department  of  Energy,  did  not  involve  any  Army  funds,  and  is 
not  controlled  by  the  Army.  I  belong  to  the  Conflict  Simulation  Laboratory  here  at 
Livermore,  that  is  completely  funded  by  the  Department  of  Energy.  Bob  Terhune,  who 
is  the  next  speaker,  also  belongs  to  the  same  organization. 

There  is  some  confusion  because  Army  people  come  up  to  me  and  say.  "Give  me  my 
model"  But  they  don’t  own  the  model.  So  if  you  want  to  find  out  about  Janus,  get  a 
hold  of  the  Janus  project  manager.  Janus  is  an  analysis  tool,  a  research  tool,  and  a 
training  tool.  There  is  a  lot  of  interest  in  training  right  now.  which  I  will  be  talking 
about. 
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We  ran  combat  simulations  from  platoon,  or  really  from  the  individual  soldier  to 
the  division  level.  We  don’t  simulate  theater  operations.  We  have  a  model  under 
development  in  our  laboratory  called  CONMOD.  which  will  be  a  corps  and  echelon 
above  corps  model  that  simulates  higher  level  activity.  We  are  not  talking  about  this 
product  today  because  it’s  in  an  early  development  stage,  but  I  am  sure  next  year  or  the 
next  time  you  have  a  conference  like  this,  we  will  have  that  project  manager  present. 

In  Janus  one  way  we  try  to  model  a  human  being  is  put  him  in  the  loop.  Players 
are  involved  in  tactics  and  doctrine.  We  don’t  automate  the  tactics  in  Janus.  We, 
however,  provided  a  non-interactive  mode  operation,  because  there  are  all  these 
statisticians  around  that  say,  I  need  to  run  17  independent  simulations,  that’s  where  the 
median  of  the  curve  is.  So  we  also  provide  that  as  an  alternate  mode. 

The  model  is  high  resolution  and  balanced.  We  don’t  model  the  forces  on  the 
bullet,  but  we  do  simulate  attrition  at  the  item  system  level.  People  shoot  at  people, 
tanks  shoot  at  tanks,  people  shoot  at  tanks,  and  so  on.  We  don't  aggregate  that 
information  through  something  like  Manchester  equations.  We  actually  stochastically 
play  the  game.  Part  of  the  reason  we  do  that  is  because  the  lab  traditionally  beats 
everything  to  death  with  computers,  and  models  the  heck  out  of  the  physics.  That’s 
what  we  are  trying  to  do. 

In  at  least  the  interactive  mode  we  force  the  simulation  to  run  at  real  time. 
Normally  it  runs  faster  than  real  time,  but  we  put  a  governor  in  there  and  force  the 
people  to  make  decisions  the  same  way  they  would  in  the  real  world,  albeit  not  always 
under  the  conditions  of  the  real  world,  but  I  guess  we  could  get  them  out.  get  them 
cold,  do  that  if  you  wanted  to. 

We  do  model  stochastic  attrition.  We  do  model  three  dimensional  terrain,  weapons 
system  characteristics  to  engineering  detail,  and  weapons  effects  to  engineering  detail. 
We  actually  use  LAMSA  based  test  data,  PK/PH  data.  This  is  very  important;  part  of 
the  philosophy  of  the  lab  is  to  be  open  about  our  product.  Our  simulator  is  data  base 
driven.  To  all  the  extent  possible,  all  of  our  data  is  under  the  control  of  the  user.  If 
you  want  to  play  some  alternative  data  base,  you  don't  have  to  recompile  the  code.  It’s 
not  true  of  all  models,  some  of  you  may  have  noticed.  If  you  want  to  simulate  snow, 
the  programmer  says,  TU  do  that  for  a  small  fee,  because  I  have  got  to  recompile  the 
parameter,  because  I  put  the  coefficient  in  a  data  statement  inside  the  code."  Of  course. 
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Janus  Is  A  System  Composed  Of: 


33 


one  of  our  main  reasons  for  Livermore’s  involvement  is  to  model  nuclear  weapons. 
That’s  why  we  are  in  this  business. 

I  said  that  Janus  is  a  system:  it’s  composed  of  computers,  host  computers,  a  whole 
family  of  them,  and  color  graphics  work  stations  or  terminals.  The  terminals  are 
Tektronics  4225  because  they  are  luminous,  high  luminescent  displays,  and  have  four 
megabytes  of  local  memory,  but  the  big  attribute  is  they  are  cheap.  Much  cheaper  than 
they  used  to  be.  They  are  15K  apiece.  You  can  put  together  a  low  end  Janus  work 
system  on  a  Tektronics  work  station  about  the  size  of  a  PC.  and  have  it  in  your  office 
these  days.  Five  years  ago  it  was  a  half  a  million  to  get  a  Janus  system  like  that.  That’s 
the  direction  hardware  is  going,  and  it’s  going  tc  get  a  lot  better.  You  need  the 
software.  I  don’t  mean  to  diminish  the  software.  The  importance  is  not  150,000  lines  of 
code  in  Janus.  You  need  people,  players,  and  analysts  if  you  are  running;  particularly 
in  the  interactive  mode  you  can  have  16  players  per  simulation,  two  per  terminal.  You 
can  add  systems;  radios,  the  output  of  other  simulators,  you  can  put  together  all  kinds 
of  games  using  Janus  as  a  driver  for  the  attrition  aspects  of  combat.  It  has  been  done.  I 
have  a  whole  list  of  studies  that  have  been  completed. 

You  may  read  in  the  literature  about  something  called  Janus  T.  In  1983,  General 
Start  saw  Janus  here,  decided  that  the  Army  should  have  it.  the  lab  cut  a  Memorandum 
of  Agreement  with  the  Army,  sent  k  nus  in  its  state  in  1983  to  the  Army,  and  they  call 
that  Janus  T.  It  still  exists.  The  models  are  different  now.  They  have  drawn  apart, 
both  in  terms  of  algorithms  and  functionality,  but  particularly  in  terms  of  hardware.  So 
I  want  to  use  this  chart  to  illustrate  the  differences  i.i  hardware. 

The  Army  has  seen  fit  to  retain  the  essential  architecture  we  had  in  1983,  when  we 
had  a  host  computer  which  did  all  the  graphics  and  applications  processing  inside  the 
host  computer,  then  sent  data  out  over  big  fat  parallel  lines  to  graphic;  display 
terminals.  We  abandoned  that  in  1983  because  we  didn’t  want  to  do  all  that  graphics 
computing  on  the  host  and  tie  up  the  machine.  You  couldn’t  get  very  far  away  from 
the  computer  with  your  graphics  display  generator  because  of  this  big  baud  rate 
requirement.  Every  time  you  have  a  terminal  you  have  got  to  do  more  graphics 
computing,  which  means  you  slow  the  system  down  by  quite  a  large  factor. 

The  graphics  code  in  the  1983  system  was  mixed  in  with  the  applications  code,  and 
we  knew  that  modern  32  bit  microprocessor  base  products  were  coming  out  and  we 
wanted  to  separate  the  graphics  out  so  we  could  exploit  the  new  capability.  We  went  to 
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Janus  Can  Operate  In  Two  Modes 


The  Janus  Simulation  System  is  Installed  at  Thirteen 
Locations  as  of  November  1 988  1 1 
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wflict  Simulation  Laboratory  Lawrence  Livermore  National  Laboratory 


kind  of  a  star  design  in  which  we  have  a  host  computer  and  it  just  does  the  applications 
processing,  and  we  have  gone  to  a  little  fancier  (and  as  it  turns  out  much  cheaper) 
terminals,  in  which  all  the  graphics  are  done  locally. 

That  means  you  don’t  need  a  high  baud  rate  line.  That  means  (among  other  things) 
that  you  off-load  the  graphics  processing  from  your  host  and  end  up  with  a  distributed 
system.  This  is  very  important,  because  the  communication  lines  can  now  be  telephone 
lines.  We  have  operated  Janus  with  the  reds  in  McLean,  Virginia,  and  the  blues  here  in 
Livermore.  You  could  theoretically  have  a  computer  in  Livermore,  and  the  eight 
stations  anywhere  else  you  wanted,  running  on  telephone  lines.  You  can’t  tell  the 
computer  is  not  in  the  next  room.  You  can  add  terminals  and  it  doesn’t  really  slow  you 
down,  unless  the  guy  on  the  terminal  starts  doing  weird  things.  We  have  decoupled  the 
graphics  from  the  physics  in  order  to  position  ourselves  for  even  more  advanced  changes 
that  are  coming  out. 

The  Janus  screen  looks  something  like  an  arcade  game,  only  a  little  fancier,  maybe 
with  a  menu.  There  are  blue  screens  and  red  screens,  and  you  can  highlight  the 
information  from  the  different  players.  You  can  do  things  during  the  game  (or  in  this 
case  before  the  game  starts)  to  find  out  what  you  can  see  from  independent  positions.  A 
cursor  gives  you  a  line  of  sight  fan. 

One  of  the  neatest  things  we  have  done  with  Janus  in  recent  months  (I  guess  in  the 
last  year)  is  added  a  capability  called  “command  control  graphics."  Command  control 
graphics  is  an  ability  to  draw  on  a  screen  in  an  overlay  plane  any  graphic  symbology  you 
want  free  hand,  or  using  precanned  symbology.  So  you  don’t  need  a  grease  pencil,  a 
transparency,  and  a  map  any  more  to  do  your  analysis,  you  can  do  it  right  on  the 
screen.  That's  nice.  What’s  even  nicer  is  that  I  can  store  that  as  a  message  and  send  it 
to  any  other  terminal  in  the  system.  So  if  you  had  one  of  these  in  San  Diego  and  you 
wanted  to  send  information  to  some  place  in  Maryland,  you  could. 

This  has  tremendous  utility  in  doing  training  for  a  commander.  You  can  give  a 
commander  a  terminal,  no  acquisition  data,  just  a  map  and  his  usual  assets,  such  as 
radios  or  pieces  of  paper,  or  however  he  gets  information.  He  creates  a  battle  plan 
based  on  his  information,  sends  it  to  his  subordinates  who  are  operational  commanders, 
and  they  execute  his  plan.  Operational  commanders  are  getting  acquisition  data  and 
they  are  fighting  the  war.  They  send  back  information,  and  might  say  "Hey,  boss,  you 
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are  all  screwed  up.  That’s  not  a  division,  that’s  a  whole  army.”  He  gets  the  information 
and  adjusts  his  plan.  You  can  see  how  this  iteration  might  work  as  a  training  process. 

I  already  mentioned  that  Janus  can  operate  in  two  modes.  In  the  interactive  mode, 
of  course,  we  can  force  real  time  play.  It  features  innovation,  very  complex 
interactions,  and  surprise.  There  is  some  difficulty  with  repeatability,  which  is  now 
going  away  because  we  are  finding  out  that  it  really  isn’t  a  difficulty.  When  you  have  a 
large  game,  you  stress  people  and  they  are  trained,  they  always  do  the  same  thing,  more 
or  less,  as  it  turns  out. 

These  are  the  current  installations  of  Janus.  This  is  not  Janus  T.  Janus  T.  is  also 
installed  (I  think)  in  eight  places  now.  Of  course,  we  have  it  here.  It’s  at  the  Army  War 
College,  Warrior  Preparation  Center  in  Germany  and  the  Atomic  Weapons 
Establishment  in  England.  All  this  work  is  being  done  under  a  joint  working  agreement 
among  the  labs.  TRADOC  in  Monterey  California,  is  an  Army  facility,  and  in  the  very 
near  future  will  be  connected  with  the  Navy  Postgraduate  School.  They  serve  as  a  Beta 
test  sight  for  us.  Both  the  Air  Force  and  the  Sandia  National  Laboratory  have  systems. 
The  last  five  installations  on  the  list  were  all  done  this  year.  IDA,  the  Institute  for 
Defense  Analysis,  bought  an  eight  terminal  system.  We  also  just  installed  an  eight 
terminal  system  at  Fort  Leavenworth  under  what’s  called  the  Thurmon  Initiative. 
When  General  Thurmon  saw  the  system  he  got  pretty  excited  about  it,  and  as  a  result  of 
that  we  gave  the  Army  a  system. 

There  have  been  numerous  studies  with  Janus,  and  I’ll  point  out  a  few  here  because 
the  Defense  Nuclear  Agency  (DNA)  is  here.  We  have  done  several  studies,  and  are 
conducting  one  right  now  for  implementing  an  upgraded  intermediate  dose  model.  Art 
Deverol  gave  a  paper  during  the  summer  showing  that  radiation  dose  effects  and  light 
effects  really  make  a  difference  on  the  outcome  of  an  engagement.  We  are  continuing 
to  work  on  this  model. 

We  have  a  users  conference  here  each  year.  We  just  had  one  about  three  weeks 
ago,  there  were  60  people  attending.  Several  papers  were  given  by  personnel  at  the 
Navy  Postgraduate  School  on  various  subjects  related  to  Janus.  They  used  the  Army 
system  located  in  Monterey.  They  said  the  Navy  didn’t  have  anything  like  this,  and  they 
were  quite  excited  about  this  utilization  of  Janus. 
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Janus  Has  Been  Used  For  Numerous  Studies. 
Selected  Examples  Are: 
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There  are  some  human  performance  modrls  in  Janus,  where  we  change 
performance  rates  for  clearing  obstacles,  getting  on  and  off  vehicles,  transferring  fuel 
or  ammunition  and  that  sort  of  thing.  We  have  a  forward  observer  model  for  artillery 
in  which  people’s  ability  to  estimate  speed  and  things  like  that  are  included. 

One  of  the  things  we  don't  want  to  do  as  modelers  is  implicitly  believe  what’s  in  a 
model.  Models  are  used  as  guidelines.  This  comes  back  to  Captain  Jones’  comment 
about  the  importance  of  knowing  what’s  in  the  model.  If  you  interpret  the  results  of 
.he  model  and  you  don’t  know  what’s  in  there,  that’s  your  problem,  not  the  model’s 
problem.  We  think  Janus  is  a  good  high  resolution  model.  We  don’t  model  everything. 
Some  of  the  things  we  don’t  model  are  human  factors.  We  don’t  model  courage,  we 
could.  You  give  me  a  courage  model  and  we’ll  model  it. 

Bob  Terhune  is  going  to  talk  about  some  upgrades  he  has  done  in  SEES  for 
acquisition  of  people  by  people.  Janus  tends  to  be  oriented  towards  acquisition  of 
systems,  tanks  and  airplanes,  and  that  sort  of  thing. 

There  are  a  number  of  things  we  just  haven’t  modeled  because  we  either  don’t  have 
the  time,  the  resources,  or  the  money.  We  have  a  long  list  of  things  that  need  to  be 
done.  In  spite  of  all  the  noise  we  make  on  Janus,  we  have  operated  the  program  with 
one  operator  analyst  and  one  project  manager.  That’s  it.  I  have  been  allowed  to  hire 
some  more  people  here  recently  and  we  are  expanding.  We  are  going  to  be  able  to 
address  some  of  these  issues  soon. 

I  am  going  to  talk  a  little  bit  about  a  new  product  called  the  ’analyst  work  station,’ 
which  I  think  should  be  of  interest  to  this  community.  Why  am  I  talking  about  this? 
Well,  if  you  have  an  interactive  war  game  or  a  war  or  field  exercise,  it’s  not  easy  to  tell 
what  happened  after  the  fact.  In  wars  it’s  really  t_  jh  because  you  can’t  get  any 
volunteers  to  stand  out  there  and  report  things,  as  in  >.«  days  of  the  scribes  when  they 
used  to  do  that.  There  is  a  lot  of  free  play,  and  you  can't  see  everything.  There  are 
tactics.  In  the  case  of  Janus,  the  controller  is  trying  to  monitor  a  game  with  the 
terminals  maybe  not  in  the  same  county.  That’s  hard  to  do.  So  we  went  out  and  built 
something  called  an  ’analyst  work  station,’  and  we  set  out  as  requirements  that  we 
minimize  development  costs  by  using  everything  we  had.  Hardware  had  to  be  the  same 
as  Janus  uses.  We  didn’t  want  the  person  using  it  to  have  to  be  a  data  base  management 
expert.  I  think  it’s  very  important  here  that  the  design  be  as  generic  as  possible,  so  we 
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AWS  Can  Represent  Simulated  Combat  Data 
Graphically  With  a  Map  Background 


A3 


could  go  to  Terry  Kolpcic  and  punch  his  results  up  on  this  system  or  any  other  model, 
and  field  test  data. 

What  this  thing  does  is  it  uses  a  color  graphics  display  system  with  a  map 
background.  We  get  to  replay  the  battle  on  a  map  background.  We  use  the  Janus 
symbol  editor  so  you  can  actually  have  tank  symbols  up  there  instead  of  little  dots,  and 
you  are  able  to  zoom,  put  grids  on.  scale,  do  all  kinds  of  neat  things.  What  it  really  is, 
though,  is  an  interactive  color  graphic  relational  data  base.  I  used  to  have  to  thumb 
through  pounds  of  paper  to  find  all  of  the  red  tanks  killed  by  nuclear  weapons  of  a 
certain  kilotonnage.  Here,  you  ask  for  that  and  they  appear  on  the  screen.  Want  to 
know  something  about  a  particular  guy,  like  why  was  he  killed?  Put  the  cursor  on  him 
and  push  a  button,  and  you  get  an  alphanumeric  readout  that  tells  you  how  much 
ammunition  he's  got,  when  he  was  killed,  why  he  was  killed,  etc. 

We  can  operate  on  output  from  Janus,  and  we  have  extensively  modeled  NTC  data. 
We  have  used  actual  training  center  data  and  field  test  data.  We  have  put  both  Janus 
data  and  ConMod  data  up  on  a  single  Janus  screen.  By  the  way,  ConMod  is  written  in 
Ada,  while  Janus  is  in  FORTRAN.  This  doesn't  make  any  difference  for  the  system. 
The  system  can  show  you  ali  of  the  red  systems  killed  in  the  first  30  minutes  of  some 
simulated  battle,  and  the  types  of  kills  are  color  coded.  You  can  tell  who  was  killed  by 
whom,  and  see  the  direct  lines  of  fire.  Tne  system  can  show  all  the  red  and  blue  artillery 
impacts,  and  the  damage  they  produced. 

We  showed  this  stuff  to  General  Mullin  at  Fort  Leavenworth.  He  really  liked  it, 
got  excited  about  it.  and  asked  if  we  could  engage  Janus  in  the  middle  of  one  of  these 
displays  and  do  "what  if"  games.  In  other  words,  play  different  tactics.  We  indicated 
that  the  system  was  not  designed  for  that  capability,  but  that  we’d  think  about  it.  Two 
days  later  we  were  able  to  push  a  button  at  any  point  in  time  during  the  analysis,  and 
engage  Janus  to  play  alternative  tactics.  We  then  presented  it  to  General  Thurmon.  who 
is  the  Commanding  General  of  TRADOC,  and  he  really  liked  it.  There  is  now  a  lot  of 
interest  in  training  applications  with  a  combination  of  these  products. 

I  presume  the  Army  is  going  to  use  something  like  this  system  at  the 
Precommanders  course,  the  Precommanders  Staff  College,  and  the  Nuclear  Weapons 
Officers  course.  These  are  the  only  groups  that  really  play  nuclear  weapons  in  a  high 
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Analysis  Of  Interactive  Wargames  Has  Been 
A  Problem 
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Requirements  For  AWS  Development 


AWS  Features  High  Resolution  Interactive  Color 
Graphics  Displays 


Conflict  Simulation  Laboratory 


The  Purpose  And  Goal  Of  The  Analyst  Workstation 
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New  Product  Will  Permit  Systematic  Validation 
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Training  Applications  Of  Janus  and  AWS 


resolution  environment.  They  are  going  to  be  using  this  system  right  after  the  first  of 
the  year. 

Validation  was  another  point  Captain  Jones  made.  With  the  analyst  work  station 
and  Janus  living  and  breathing  in  the  same  environment,  for  the  first  time  we  can 
balance  field  test  exercises  against  the  combat  simulation,  run  them  in  an  integrative 
fashion,  and  fix  the  models  that  aren’t  right. 

I  am  working  with  Bill  Wasser  and  Dr.  Bryce  at  what  used  to  be  SEADAK  at  Fort 
Ord.  They  want  acquisition  tests;  very  high  resolution  tests.  We  are  going  to  be  able  to 
run  acquisition  data  through  this  system,  see  where  the  acquisitions  were  made,  then  run 
Janus  on  the  same  scenario,  and  see  where  the  acquisition  model  made  the  acquisitions. 
In  this  way  we  can  see  if  there  is  any  similarity  at  all  between  the  theoretical  model  and 
what  people  really  did.  This  effort  may  riot  only  allow  us  to  fix  the  combat  model,  but 
we  might  also  be  able  to  encourage  the  field  test  guys  to  take  the  right  data  so  that 
everybody  uses  the  same  basis. 

I  only  have  a  couple  more  charts  that  I  use  to  tell  people  what  we  have  been  doing 
lately.  We  have  put  out  a  whole  new  set  of  documentation  and  released  something 
called  Janus  4.0.  We  have  installed  it  at  five  new  sites.  We  are  now  operating  on 
things  like  the  MicroSAINT  3500,  the  MicroSAINT  Station  3500,  the  6220,  a  VAX  8900 
and  600,  and  any  MicroVAX  DEC  machine.  We  have  revised  and  improved  the  analysis 
work  station.  Previously,  we  had  to  use  INGRES  or  FRAMIS  data  base  to  get  data.  Now 
we  no  longer  have  to  do  that.  We  now  are  able  to  import  FORTRAN  data  files  right 
out  of  Janus.  The  upshot  of  that  is  the  INGRES  license  (which  costs  nearly  as  much  as 
the  little  computer)  is  no  longer  needed,  and  cost  can  be  significantly  reduced. 

Recently,  we  ran  Janus  here  for  the  Army  as  part  of  mission  area  analysis  doing 
what  was  called  a  nuclear  excursion  study  involving  DNA  and  the  Army.  We  ran  the 
biggest  game  ever  run  on  Janus,  there  were  actually  4,300  individual  item  systems. 
This  is  roughly  what  you  might  consider  as  a  blue  division  against  the  red  division.  It 
was  a  big  game.  Very  successful.  There  are  some  papers  being  written  on  that  exercise. 

We  have  done  some  off -site  demonstrations.  This  is  fairly  new.  We  are  able  to 
take  a  machine  the  size  of  a  couple  of  terminals,  put  them  on  an  airplane,  and  go 
somewhere  and  put  on  a  demo.  We  have  done  this  for  General  Mullen,  and  General 
Thurman  at  the  Pentagon. 
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Our  users’  conference,  (analogous  to  this  meeting)  had  about  60  participants.  There 
were  20  some  papers  given  over  three  days.  I  think  there  was  a  paper  given  by  a 
Marine,  two  papers  given  by  Navy  people,  and  several  efforts  by  Naval  Postgrad 
School. 

My  last  chart  deals  with  future  plans.  It’s  a  little  bit  dated  already. 

We  are  modeling  (among  other  things)  special  mu.iitions  here,  particularly 
MLRSTGW  for  the  Office  of  Munitions.  In  doing  so  wv.  mnd  some  difficulties  in  the 
line  of  sight  operations,  which  we  think  is  the  best  one  known  to  man.  but  it  isn’t  good 
yet.  There  is  a  trade-off  between  compute  time  and  accuracy,  and  we  have  some  ideas 
that  we  are  going  to  be  implementing. 

When  you  get  to  large  games  like  the  division  game,  we  have  a  control  problem. 
Janus  was  not  set  up  to  control  big  units,  so  we  are  going  to  have  to  use  some  form  of 
templating.  We  currently  control  at  the  platoon  and  combat  levels,  and  we  need  to 
control  at  a  slightly  higher  level  in  order  to  do  a  bigger  game.  Currently  Janus  plays  on 
a  400  by  400  grid,  and  you  get  to  pick  the  grid  size,  depending  on  your  needs.  We  have 
increased  that  to  a  thousand  and  probably  could  go  quite  a  bit  higher.  It’s  more  of  a 
memory  issue  than  it  is  anything  else,  and  there  is  lots  of  memory  these  days. 

Internally  we  are  doing  quite  a  bit  of  work  here  inside  the  lab  for  the  first  time. 
We  have  convinced  the  outside  world  to  use  it.  and  now  we  almost  have  the  lab 
convinced  to  use  Janus.  That’s  a  real  breakthrough.  They  have  some  pretty  exotic 
weapon  studies  going  on  here  that  are  line  of  sight  type  weapons.  So  three  dimensional 
terrain  and  having  a  combat  environment  is  important. 


(Brief  recess  taken). 


CDR  BERGHAGE:  Sorry  to  call  you  back  early  from  your  coffee  break,  but  there 
was  an  addition  to  Janus  that  we  wanted  to  cover,  and  in  order  to  work  that  into  the 
time  schedule,  we  had  to  cut  the  coffee  break  short. 
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Janus  Highlights  Since  November  1 987 
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Janus  Architectural  Improvement  Since  1983 


Human  Performance  Models  In  Janus 
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Popup  Is  A  Combination  Of  Human  Limitations 
And  T  actios 
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The  next  speaker  is  George  Anno;  he  is  going  to  talk  about  Crew  III,  which  is  an 
addition  to  the  Janus  model  for  handling  the  human  factor  types  of  information. 

ADDRESS  BY  MR.  GEORGE  ANNO 

MR.  ANNO:  First  of  all,  I  am  ^oing  to  mention  that  I  am  part  of  the  IDP  Mafia, 
of  which  Dennis  Kelleher  was  an  early  member.  I  notice  most  of  this  Mafia  sitting  over 
here  on  the  left  side  grinning.  The  godfather  is  over  there,  and  he  has  the  largest  grin 
on  his  face.  Dr.  Young  from  DNA  (Defense  Nuclear  Agency)  has  supervised  and  led  this 
process  from  its  start. 

The  need  was  basically  established  through  the  U.  S.  Nuclear  and  Chemical  Agency, 
under  the  direction  of  the  Army,  who  is  interested  in  developing  manuals  and  training 
aids,  etc.  for  the  TRADOC  organization.  We  had  a  meeting  with  the  TRADOC  people, 
and  they  gave  us  a  lot  of  insight  regarding  what  we  should  be  looking  at  in  terms  of  our 
tactical  battle  field  situation.  We  couldn't  do  all  the  various  elements;  the  helicopters, 
the  medical  people,  the  rear  echelons,  etc.  So  we  asked  them  what  were  the  important 
battle  field  elements  that  we  should  really  be  looking  at  in  order  to  characterize  the 
situation?  They  came  up  with  four  different  crews.  Actually,  three,  but  there  is  a 
composite  one.  They  came  up  with  the  tank,  the  tow,  the  tow  vehicle  and  artillery, 
whose  elements  are  the  Fire  Direction  Center  (FDC)  and  also  the  gun  crews.  Each  one 
of  those  small  units  has  four  crews  and  four  crew  members  except  for  the  FDC;  they 
have  three.  So  what  we  wanted  to  do  was  to  model  those  small  elements.  Prior  to  this 
we  had  talked  to  the  Janus  people  and  they  indicated  that  they  just  look  at  the 
movement  of  units.  What  we  want  to  do  was  to  look  at  the  performance  of  these  crews 
by  combining  the  degradations  of  the  various  crew  members  within  the  small  tactical 
unit.  We  wanted  to  look  at  how  the  crew  members  worked  together,  how  they  did  their 
various  jobs,  and  how  well  they  coordinated  their  efforts. 

The  first  thing  we  had  to  do  was  to  try  to  establish  how  are  were  going  to  evaluate 
the  radiation  insults,  and  how  those  insults  propagate  from  a  radiation  exposure.  So  how 
do  we  actually  characterize  those  insults?  We  decided  to  characterize  the  insults  in 
terms  of  the  symptomatologies  that  would  develop.  For  example,  the  upper  GI 
syndrome,  the  vomiting,  the  nausea,  the  lower  Gl  syndrome,  diarrhea,  fatigability, 
weakness,  fluid  loss  and  all  the  bad  things  that  really  degrade  performance.  Where  can 
we  get  this  data?  A  lot  of  it  had  been  generated  prior  to  this  project,  but  it  existed  in 
bits  and  pieces  here  and  there  among  the  various  parts  of  the  military. 
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Colonel  Pickering,  for  example,  did  an  enormous  amount  of  work  for  the  Air  Force 
in  making  these  kinds  of  assessments  for  armor  crews,  fighter  aircraft,  and  attack 
aircraft.  So  we  also  went  to  Dr.  Pickering  and  talked  to  him  about  this  issue.  There 
were  various  other  individuals  that  were  in  the  group  that  helped  develop  this  IDP 
process.  They  came  from  various  areas  of  the  military,  the  medical  community, 
universities,  and  the  national  laboratories. 

We  sort  of  went  through  a  process  of  multidisciplinary  guidance  so  that  we  would 
establish  this.  As  we  established  the  symptomatology  we  developed  those  parameters 
that  described  symptomatology  progression  such  as  the  onset  of  the  problem  post 
irradiation.  That  is,  an  acute  pulse  from  let's  say  an  atomic  weapon,  how  quick  or  how 
fast  these  symptoms  would  develop,  how  severe  they  would  get  in  what  time  frame,  and 
how  long  they  would  last.  The  information  that  we  used  to  develop  the  IDP  was  sort  of 
a  kaleidoscope  of  things.  We  got  information  based  on  nuclear  accidents  in  industry. 
There  has  been  something  like  100  accidents,  and  maybe  about  40  of  them  are  more  or 
less  useful  in  the  dose  range  that  we  are  interested  in.  The  IDP  intermediate  dose 
basically  covers  a  range  of  somewhere  between  75  to  4500  rads.  This  range  more  or  less 
set  the  tone  for  the  levels  of  performance  degradation  we  looked  at  and  focused  on.  All 
of  this  work  of  course  is  looking  forward  to  trying  to  develop  a  crew  model  ultimately. 
We  got  information  from  the  nuclear  accidents,  therapy  patients,  and  various  clinical 
institutions  around  the  United  States  and  the  rest  of  the  world.  We  also  looked  at  the 
Japanese  atomic  bombings  (the  experience  there),  and  bomb  test  accidents  from  the 
Pacific  testing  sites. 

We  also  looked  at  animat  data  from  the  standpoint  of  performance,  particularly 
the  heat  side,  which  is  the  early  transient  incapacitation  of  animals.  We  are  pretty  sure 
numans  suffer  the  same  effect.  We  have  seen  this  in  two  accidents.  We  obviously 
cannot  perform  an  experimental  study  using  human  beings,  so  we  are  looking  at 
retrospective  data  and  trying  to  sort  it  out.  It's  quite  a  hodgepodge  of  information.  We 
were  quite  successful  in  establishing  a  dose  time  map  of  these  various  symptom  groups. 
We  have  divided  the  symptoms  into  six  different  groups,  and  I  can  get  into  tha*  more 
later. 

These  symptoms  more  or  less  describe  the  initial  stage,  that  is  to  say,  the  initial 
response  when  sickness  comes  on  anywhere  from  a  few  hours  or  to  where  you  get  maybe 
3,000  rad,  and  the  onset  is  within  about  15  minutes.  For  lower  doses  the  onset  is  sort  of 
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an  insidious  thing  that  develops  over  a  period  of  two  or  three  days  and  sort  of  levels 
out,  depending  on  the  d^se.  After  the  initial  stage  there  is  another  period  which  comes 
on  days  to  weeks  later,  which  is  known,  as  some  of  you  are  familiar  with,  as  the 
hemopoietic  effects.  Eplasia  in  the  blood  system  develops,  and  I  think  we  have  seen  a 
lot  of  that  from  the  Chernobyl  accident.  Incidentally,  the  Chernobyl  incident  has 
provided  us  an  opportunity  to  verify  our  symptomatology  assessment. 

The  next  step  we  needed  to  perform  was  to  take  our  symptomatology  descriptions, 
and  put  them  into  some  plain  words  that  people  would  understand.  Once  this  was 
accomplished  we  took  our  list  to  the  military  crews  that  we  had  selected,  that  is,  the 
tank,  the  tow  vehicle,  and  so  forth.  We  went  to  various  military  installations  to 
interview  experienced  people  who  had  actually  had  some  experience  in  combat,  Vietnam 
and/or  Korea.  We  wanted  individuals  who  had  experience  with  the  equipment  and  knew 
how  troops  would  function  in  a  situation  where  they  were  seriously  degraded.  We 
wanted  to  know  how  they  felt  the  various  symptomatology  would  lengthen  the  time  to 
perform  the  combat  task. 

We  used  the  "performance  time*  parameter  because  when  we  asked  troops  about 
accuracy  and  that  sort  of  thing,  they  said.  "Well,  hell.  We  just  put  a  shell  in  the  breach 
and  we  just  keep  crashing  it  in  until  it  goes  in."  There  is  not  much  of  an  accuracy  issue 
there  at  all.  The  only  system  that  really  had  an  accuracy  issue  was  the  TOW  wire 
guided  missile,  which  you  have  to  keep  guiding  to  the  target.  We  were  convinced  that 
the  time  extension  for  complying  these  tasks  was  the  important  parameter,  and  we 
stuck  with  that.  To  quantify  the  subjective  responses  we  wanted  to  use  the  Delohi 
technique,  so  we  talked  to  the  inventor  of  the  Delphi  process  at  the  Rand  Corporation. 

What  we  ended  up  with  is  basically  a  self  evaluation  process  where  you  are  asked  to 
make  judgments  on  how  much  time  a  task  would  be  extended  if  the  following  symptoms 
were  present.  In  describing  the  symptoms  we  struggled  with  the  terms  in  order  to  make 
sure  that  these  Army  guys  understood  in  plain  language  what  we  were  talking  about. 
We  used  "coming  down  with  the  flu"  as  one  of  the  key  descriptions  so  that  they  could 
relate  their  experience  to  the  symptomatology  found  in  radiation  victims.  Most  of  the 
troops  could  easily  relate  to  vomiting,  nausea,  and  the  other  symptoms  from  personal 
experience.  The  questionnaire  process  gave  us  the  data  that  we  needed  to  relate  the 
symptomatology  to  performance  decrements. 
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Each  individual  interviewed  gave  us  their  individual  judgments  regarding  the 
lengthened  time  required  to  perform  a  given  task,  or  whether  they  could  perform  it  at 
alL  The  anchor  points  on  the  questionnaire  were:  "I  couldn’t  do  it  at  all."  or,  "It 
wouldn't  be  any  problem  whatsoever."  We  also  obtained  field  measurements  to 
determine  the  normal  time  that  it  took  to  do  all  these  jobs.  These  were  done  at  the 
various  Army  centers  around  the  country,  such  as  Fort  Knox  and  Fort  Benning.  The 
troops  performed  simulator  tests,  and  also  some  field  tests  to  develop  the  normal  base 
times  and  variances  for  the  selected  tasks. 

The  statistical  analysis  of  these  timed  tasks  has  developed  into  what  is  now  called 
the  "Crew  III"  model.  The  Crew  III  model,  as  it  has  developed,  has  become  a  module 
for  inclusion  in  the  Janus  program.  It  is  important  to  remember  that  the  Crew  III 
model  a  process.  It’s  not  like  a  SAINT  model  that  is.  a  canned  situation,  where  you 
can  ji  ^ort  of  overlay  and  put  things  in.  Crew  III  is  not  that  general.  You  have  to  sit 
down  and  draw  diagrams  out.  you  have  to  develop  a  process  for  a  period  of  time. 
Basically  it's  a  period  of  time  flow  chart  or  event  analysis.  We  have  performed  the 
analysis  for  the  four  selected  crews  tasks.  Each  one  of  the  periods  selected  for  analysis 
was  a  critical  part  of  mission.  We  took  critical  performance  times  and  related  them  to 
the  dose  response  time  curve.  The  integration  of  this  relationship  is  the  basis  of  the  Crew 
III  model,  which  is  being  used  in  Janus. 


MR.  BANKS:  I  would  like  to  introduce  the  next  speaker  to  you.  He  is  Bob 
Terhune  from  the  Lawrence  Livermore  National  Laboratory;  he  will  talk  to  you  about  a 
relatively  new  model  called  SEES.  It  has  an  orientation  towards  special  warfare.  It  can 
be  used  for  small  force  on  force  engagements,  and  terrorist  activities. 

ADDRESS  BY  MR.  ROBERT  W.  TERHUNE 

MR.  TERHUNE:  What  we  are  going  to  talk  about  is  the  development  of  a  site 
security  model.  We  are  trying  to  model  humans  in  small  arms  combat.  That’s  the  area 
I  am  going  to  try  to  focus  on  for  this  presentation.  We  have  been  working  on  this 
program  for  two  years  now.  One  of  the  first  things  we  did  was  build  a  prototype  from 
Janus.  We  took  Janus,  modified  it.  and  built  a  prototype  to  demonstrate  the  concept. 
The  rest  of  the  time,  until  just  recently,  we  have  been  in  what  we  call  the  requirement 
and  analysis  phase.  We  are  putting  in  an  awful  lot  of  effort  up  front  working  with  the 
prototype  and  working  with  the  PSO  guards  to  develop  the  requirements  and  the 
information  that  we  need  to  understand  the  problems  before  we  go  into  coding  or  a 
design  phase. 

OSE,  the  Office  of  Security  Evaluations,  has  asked  us  to  provide  a  means  for  a  site 
to  enhance  its  security.  They  wanted  to  conduct  force  on  force  exercises  for  the 
evaluation  of  the  security  force  performance.  They  also  wanted  a  means  to  supplement 
their  training  program  in  Command  Control,  Communications  and  Tactics  for  PSOs, 
sergeants,  lieutenants,  and  the  security  inspectors.  We  felt  a  model  based  on  Janus,  but 
using  small  arms  combat  would  be  the  most  ideal  thing  to  do.  It  was  this  concept  that 

we  actually  named  the  model  after  the  "Security  Exercise  Evaluation  Simulation" 

(SEES). 

A  force  on  force  exercise  involves  a  group,  essentially  a  SWAT  team,  acting  in  the 
role  of  terrorists,  trying  to  penetrate  laboratory  security.  They  sneak  into  the 
laboratory  at  odd  hours  and  try  to  take  over  the  facility.  The  object  of  the  exercise  is  to 
see  how  well  the  security  force  here  at  the  laboratory  responds  to  the  threat.  They  use 

MILES  gear  and  it  gets  pretty  realistic.  It  would  be  nice  to  be  able  to  simulate  the 

exercise,  because  it’s  very  expensive  to  carry  them  out  month  after  month.  We  wanted 
something  that  would  help  us  to  simulate  this  process,  and  allow  us  to  supplement  some 
of  these  exercises  with  a  computer  simulation. 


SEES  Project 

Developing  a  Site  Physical  Security  Model 


Project  Review 


Presentation  by: 
Robert  W.  Terhune 
D-OWislon,  LLNL 


Immrnoam  Lhmmmm  UtMmml  Latmmtmy 


We  are  in  the  process  of  developing  a  Site  Physical 
Security  Computer  Model.  This  model  is  called  the 
Security  Exercise  Evaluation  System.  This  presentation 
is  a  review  of  the  SEES  project  We  will  present  the  SEES 
review  in  the  following  order. 

•  The  goal  motivating  the  development  of  the  model. 

•  A  brief  description  of  the  model. 

•  A  description  of  the  data  requirements. 

•  Examples  of  how  the  model  can  be  used. 

•  The  development  plan  for  the  SEES  model. 

•  The  capabilities  of  our  current  prototype. 

•  Additional  features  being  added  to  our  next  version. 

•  Summary. 


Historical  Background 


Sept  86  Julio  Torres,  DOE,  Director  Office  of  Security  Evaluations, 
requested  LLNL  to  develop  a  simulation  that  would  provide 
a  broader  baseline  for  evaluating  site  security  force 
performance  where  the  rating  is  based  on  a  mixture  of 
simulations  and  actual  field  test  exercises. 

Nov  36  Modified  the  Janus  combat  model  to  prototype  a  security 
model 

*  A  meter  resolution. 

*  Trees  for  buildings,  trees  and  natural  barriers  for  walls. 

*  Rivers  for  fences,  abatis  for  doors 

*  Tanks  for  people,  sensors  for  CCTV  cameras. 

*  Weapons  •  LAWs,  automatic  rifles. 


Historical  Background 


March  87  Completed  SEES  user  requirements. 

August  87  Completed  prototype  for  terrain  editor  and  SEES  1.0 

*  0.1  meter  resolution 

*  Buildings,  walls,  doors  and  fences  as  objects. 

*  Robot  like  human  model. 

*  Weapons*  LAWs,  pistols,  automatic  rifle. 

May  88  Used  SEES  for  planning  and  analysis  of  Force  on  Force 
field  exercise. 

October  88  Completed  SEES  analysis  and  design 

*  Information  model.  State  diagrams. 


Mode!  is  Supported  by  OSE  to  Simulate 
the  Security  Force  on  Force  Field  Exercise 


•  Provide  a  means  tor  a  site  to  enhance  and  focus  the  use  of  force  on 
force  exercises  in  evaluation  of  Its  security  force  performance. 

•  Provide  a  means  to  supplement  the  training  program  tor  security 
inspectors  In  command,  control,  communications  and  tactics. 


•  This  concept  led  tc  the  model's  name  of 
Security  Exercise  Evaluation  Simulation.  (SEES) 


liAn 
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The  director  of  OSE  came  to  LLNL  with  a  request  to  develop 
a  model  which  would  simulate  a  Security  Force  on  Force  Reid 
Exercise.  The  purpose  was  to  provide  a  broader  baseline  for 
evaluating  site  security  force  performance  where  the  rating  is 
based  on  a  mixture  of  simulations  and  actual  field  test 
experience. 

We  named  the  model  the  Security  Exercise  Evaluation 
Simulation  (SEES) 
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The  figure  lays  out  the  spectrum  of  conflict  scenarios  that  we  are  trying  to  cover. 
ConMod  covers  very  large  engagements.  Janus,  of  course,  is  kind  of  an  in  between 
model.  SEES  is  designed  for  combat  in  a  highly  detailed  area  like  urban  combat,  gorilla 
war,  infiltration  problems,  security  problems,  rescue  and  sabotage. 

Right  now  our  primary  focus  is  on  the  security  area,  because  that’s  where  our 
funding  is  focused,  but  we  are  willing  to  explore  other  applications  as  people  decide  that 
they  want  to  fund  the  development  of  these  areas.  SEES  is  being  designed  to  model  all 
aspects  of  an  armed  intrusion  against  a  secure  site.  In  SEES,  we  are  modeling  buildings 
of  various  heights,  and  also  the  interiors  of  the  buildings.  We  ar<*  modeling  such  things 
as  fences,  different  types  of  terrain  or  ground  surfaces.  TV  camera  surveillance,  and 
alarm  systems.  But  most  importantly,  we  are  modeling  people,  and  we  are  modeling 
people  engaged  in  combat.  We  are  modeling  people  doing  tasks  such  as  breaching  a 
fence,  climbing  a  fence,  running,  acquisition  or  targeting  and  searching.  We  are 
modeling  people  dealing  with  various  types  of  equipment  such  as  gas  masks,  binoculars, 
etc.  These  are  the  types  of  things  that  we  are  trying  to  model. 

The  thing  that  you  really  need  to  model  this  stuff  is  data.  You  have  to  have  a  tie-in 
with  the  real  world.  We  feel  that  measured  data  and  expert  opinion  are  going  to  be  the 
key  tc  SEES’  realism.  We  are  trying  to  model  the  physics  of  events  supported  by 
measured  data,  especially  in  areas  such  as  acquisition,  movement,  barrier  penetration, 
targeting,  and  other  performance  skills.  We  are  trying  to  develop  SEES  with  the 
consultation  and  advice  of  numerous  organizations  with  expert  knowledge  in  weapons, 
small  arms,  combat,  maps,  terrain  effects,  security,  safeguards  and  human  performance. 
We  are  using  expertise  at  CTA,  the  DOE  training  academy  in  Albuquerque  for  security 
inspectors.  We  are  trying  to  arrange  an  agreement  with  the  U.  S.  Military  Police 
School  to  provide  them  a  SEES  model,  so  they  can  begin  using  the  system.  They  can 
provide  us  with  feedback  on  the  model’s  accuracy,  and  provide  us  with  data  on  combat. 

We  are  working  very  closely  with  our  own  PSOs  here  at  Livermore.  They  actually 
come  in  and  work  the  prototype  and  give  us  input  on  what  works  and  what  doesn’t.  We 
have  had  contact  with  AMSAA,  and  we  work  with  them  in  order  to  use  the  Army 
approved  data  for  the  various  weapons’  effects.  We  have  also  worked  with  the  U.  S. 
Army  Topographical  Laboratory  in  terms  of  the  environment,  and  the  terrain. 
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SEES  provides  a  means  to  extend  the  modeling 
of  the  spectrum  of  conflict  scenarios 


The  Conflict  Simulation  Center  had  developed  a 
battalion  size  model  for  mechanized  combat  in  Janus  and 
was  developing  the  requirements  for  a  Corps  size  Battle 
management  model. 

SEES  provided  a  means  to  extend  the  model  to 
simulate  Unconventional  War  and  detailed  small 
engagements.  While  the  consequences  of  any  single 
terrorist  act  is  relatively  small,  the  large  number  of 
incidences  makes  it  a  significant  factor  in  the  spectrum  of 
conflict  scenarios. 
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SEES  is  being  designed  to  model  ail  aspects 
of  an  armed  intrusion  against  a  secure  site 


SEES  is  a  highly  detailed  small  arms  combat  model.  This  picture 
represents  many  of  the  aspects  of  an  armed  intrusion  against  a 
secure  site  that  can  be  modeled  with  SEES.  Intruders  armed  with 
various  weapons  have  cut  through  an  alarmed  fence,  slowly  crossed 
an  assessment  area,  cut  through  a  second  alarmed  fence  to  enter 
the  secure  area.  Sensors  on  the  fences  and  within  the  assessment 
area  have  triggered  the  alarms  and  the  intrusion  is  verified  with 
CCTV  cameras.  Guards  have  responded  to  the  alarms  to  engage  tin 
intruders. 

Simple  terrain  features  such  as  fields  and  roads  are  modeled. 
Fences,  walls,  and  doors  are  modeled  as  breachable  barriers. 
Breaching  is  modeled  as  a  time  delay  based  on  the  data  for  each 
barrier  type  from  the  Barrier  Technology  Handbook,  Sand77-0777rev 
1987. 

Site  characteristic  data  are  developed  using  a  terrain  editor, 
which  provides  a  quick  method  digitizing  from  a  map  of  the  site  and 
assigning  attributes  to  each  object  The  LLNL  digitized  site  consists 
of  about  14  miles  of  road,  500  exterior  buildings,  5  miles  of  fence, 
and  one  interior  building  inside  of  one  square  mile,  it  took  about 
four  days  to  put  the  site  characteristic  input  data  for  the  Livermore 
site  into  the  computer.  Periodic  updates  take  about  one  half  hour. 

SEES  is  characterized  as  a  high  resolution,  event  sequenced, 
stochastic,  two  sided,  interactive,  graphic  simulator. 


Our  philosophy  is  that  SEES  will  be  based  on  individual  performance  data,  and 
tested  against  field  exercise  observations.  We  take  a  group  of  individuals  and  run  them 
through  a  performance  test.  We  take  80  guys  and  run  them  40  yards  and.  time  them. 
We  have  a  distribution  of  how  long  it  takes  those  80  guys  to  run  40  yards.  We  are  going 
to  do  the  same  thing  for  a  mile,  a  half  mile,  and  so  forth.  You  run  them  through  these 
performance  tests  and  you  get  distribution  parameters.  From  those  distribution 
parameters,  we  derive  the  input  for  the  model. 

After  the  input  we  do  a  SEES  simulation  of  a  force-on-force  exercise,  and  we  get 
certain  outcomes.  Now  we  go  into  the  field  and  we  take  the  same  group  of  individuals 
and  we  put  them  through  different  tasks.  It’s  a  force-on-force  field  exercise.  We  go 
out,  make  the  observations  of  that  exercise  based  upon  the  same  plan  that  we  used  in  the 
force-on-force  simulation.  We  come  back  and  we  analyze  the  data,  we  compare  the 
observations  here  with  some  of  the  simulation  outcomes.  This  comparison  indicates 
where  we  are  good  and  where  we  are  bad.  where  we  have  missed  the  mark,  and  where 
we  have  hit  it.  As  new  specifications  are  developed,  we  modify  the  model  and  then 
repeat  the  testing  process  again. 

Another  thing  that's  nice  about  this  is  that  we  are  really  modeling  a  simulation  in  a 
sense.  This  gives  us  a  stepping  stone  into  looking  at  real  data,  because  we  can  go  out  and 
measure  what  these  guys  do  in  a  force-on-force  exercise.  If  we  can  take  that  force  on 
force  exercise  and  model  it  in  the  simulation,  then  we  can  use  our  model  for  making 
estimates  of  real  world  situation.  What  the  model  is  lacking  is  good  data  on  how  people 
perform  the  tasks,  and  on  the  time  it  takes  to  complete  various  tasks.  We  have  actually 
measured  data  from  DOE  on  how  long  it  takes  to  go  through  barriers  using  certain 
tools,  and  we  use  this  type  of  data  in  the  actual  model. 

One  of  the  things  that  we  are  developing  now  is  a  physical  exertion  model.  The 
model  is  simple,  but  realistic. 

I  mentioned  earlier  that  we  ran  all  the  PSOs  here  at  the  laboratory  and  collected 
measurements  for  the  times  to  run  40  yards.  We  did  the  same  thing  at  a  half  a  mile, 
and  also  in  a  mile.  The  next  figure  shows  the  results.  The  two  parallel  lines  were 
obtained  from  standard  handbooks  and  record  books.  The  top  line  is  a  four 
mile-an-hour  walk  at  a  constant  rate.  People  don’t  seem  to  tire  over  that  distance.  The 
bottom  line  indicates  world  record  times  for  various  distances.  The  linear  nature  of 
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Measured  Data  and  Expert  Opinion 
are  key  to  SEES  realism 


•  Modals  tha  physics  of  wants  supported  by  maasurad  data 
CZ  Acquisition  ^Movamant^  Penatratlon*^) 

C^Targatlrig""^  Parfonnanca  Skills'"^ 

SEES  Is  being  developed  with  tha  consultation  and  advice  of  numarous 
organizations  with  expert  knowledge  In  weapons,  small  arms 
combat,  maps  and  terrain  effects,  security  safeguards,  and  human 
performance. 


||  CTA  |j  LlNLPSO'a  p 


U.S.  Army  Military  Police  School 


AMSAA 


U.S.  Army  Topographical  Lab 
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SEES  models  the  physics  of  events,  supported  by  measured  data. 
Acquisition  of  targets  are  based  on  field  experiments  involving 
hundreds  of  soldiers  viewing  stationary  and  moving  targets  on  a 
terrain  with  various  degrees  of  clutter.  Movement  is  based  on  time  - 
distance  performance  tests  of  protective  service  officers.  The 
methods  and  times  required  to  penetrate  doors,  walls  and  fences  are 
based  on  actual  field  tests  by  Sandia  Laboratory,  Aibq.,  for  DOE  and 
published  in  the  Barrier  Technical  Handbook. 

SEES  is  being  developed  with  the  consultation  and  advice  of 
numerous  organizations  with  expert  knowledge  in  weapons,  small 
arms  combat,  maps  and  terrain  effects,  security  safeguards,  and 
human  performance.  These  organizations  are  expected  to  be  users  of 
the  model,  generate  data  for  the  model  within  their  expertise,  and 
provide  expert  opinions  on  the  model's  performance. 

SEES  simulation  of  real  life  behavior  will  be  confirmed  using 
individual  performance  test  data,  and  observations  from  field 
exercises. 
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Physical  exertion  model  for  phase  2  is  simple 
but  realistic. 


Phase  2  Mobility  Model 


SEES  will  be  based  on  individual  performance  data 
and  tested  against  field  exercise  observations. 
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SEES  is  being  dr  'eloped  to  take  measured 
performance  data  and  use  it  directly  for  data  input  and 
system  parameter  values.  Distribution  parameters  will 
allow  stochastic  variation  of  performance  between 
repeated  events.  We  plan  to  complete  the  loop  of  measured 
individual  performance  input  Into  SEES  then  simulate 
actual  field  exercises,  compare  the  simulation  outcomes 
with  field  observations,  modify  the  model,  and  repeat  the 
process  until  the  model  meets  the  expectations  of  experts 
in  physical  security,  urban  combat,  and  human 
performance. 

A  force  on  force  field  exercise  was  recently  planned 
using  the  SEES  simulator ,  and  data  collected  from  the  field 
exercise  was  used  to  test  and  improve  the  behavior  of  the 
prototype.  We  Identified  that  combat  In  the  field  w?s 
considerably  less  intense  than  the  simulated  combat  This 
occurred  because  SEES  did  not  model  engagement  from 
cover.  We  put  a  prototype  "engagement  from  cover  model" 
into  SEES  and  found  a  considerable  difference  in  the 
casualty  rate  on  both  sides  as  was  observed  in  the  field 
exercise. 

The  SEES  project  needs  human  performance  data  on 
endurance  and  fatigue  and  the  benefits  of  rest  in  a  number 
of  areas  such  as  movement,  detection,  and  combat 
performance. 
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these  relationships  allows  us  to  interpolate  the  times  for  distances  not  actually 
measured. 

Based  on  this  information  we  developed  a  simple  algorithm  to  account  for  the 
effect  of  being  tired  and  fatigued.  This  is  not  a  sophisticated  model  of  fatigue.  We  are 
just  trying  to  account  for  its  effect  in  some  way.  We  are  in  the  stone  age  here  with  this 
type  of  modeling.  This  is  intended  to  get  us  going.  This  is  not  where  we  want  to  be. 
This  algorithm  gives  us  the  effect  of  the  distrnce-time  relationship.  As  you  go  farther 
and  farther,  you  slow  down.  You  cannot  sprint  for  a  long  distance.  We  have  also 
incorporated  a  very  simple  rule  of  thumb  model  that  we  picked  up  from  our 
physiologists  here  at  the  Laboratory.  They  indicate  that  it  takes  roughly  three  minutes 
of  rest  in  order  to  get  a  minute’s  benefit  on  our  curve. 

These  are  very  simple  models  to  get  us  started.  I  want  to  emphasize  that  what  we 
need  is  a  real  movement  model.  We  hope  that  something  uke  this  would  evolve  to 
where  we  can  use  the  rate  that  energy  is  expended  and  compare  this  with  various 
factors  such  as  terrain  postuie.  running,  walking,  sprinting  or  whatever.  It  would  be 
nice  to  be  able  to  get  the  amount  of  energy  expended  to  do  these  tasks,  and  then 
compare  it  to  an  endurance  rate,  where  the  endurance  is  the  energy  expended  as  a 
function  of  time. 

We  are  trying  to  do  a  similar  thing  for  modeling  target  acquisition.  We  used 
information  based  on  experimental  data  obtained  by  the  U.  S.  Army.  They  took  90 
stationary  observers  and  had  single  individuals  move  along  a  path  at  various  speeds. 
They  went  across  walking,  a  slow  run,  and  a  fast  run.  At  a  certain  point  in  time, 
observers  had  line  of  sight  view  to  these  individuals.  The  Army  measured  how  long  it 
took  to  detect  the  individuals.  We  took  this  data  and  they  worked  it  up  using  linear 
regression  into  a  log  normal  distribution.  We  were  able  to  take  this  distribution  and 
develop  an  algorithm  that  allows  us  to  predict  how  long  it  will  take  to  make  a  line  of 
sight  acquisition.  This  is  the  type  of  thing  we  are  going  to  try  to  put  in  the  model.  One 
of  our  basic  objectives  is  to  do  research  with  each  phase  of  the  project,  and  the 
acquisition  model  is  this  year’s  research  problem. 

We  are  also  going  to  try  to  model  human  performance  skill  levels  by  using 
performance  distribution  data.  We  take  a  performance  skill  and  get  a  measure  of  the 
average  performance  of  a  group,  along  with  a  measure  of  variance.  We  use  this 
performance  skill  distribution  to  perform  Monte  Carlo  simulations.  We  do  a  random 
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Movement  algorithm  is  simple  and  based  on 
measured  data 


The  model  for  acquisition  is  based  on 
experimental  data  obtained  by  US  Army. 

Crossing  spaati :  Walking,  slow  run,  and  fast  run. 
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draw-out  to  determine  the  actual  performance  of  each  event.  The  results  of  any 
particular  event  could  vary  depending  on  the  performance  that  one  gets  on  the  random 
draw.  Our  model  gives  the  analyst  control  of  how  good  he  wants  his  people  to  be.  He 
can  model  them  all  as  supermen,  or  he  can  make  them  average,  or  he  can  make  them 
wimps,  whatever  he  desires. 

As  part  of  our  program  we  are  developing  utilities  for  Janus  that  will  simplify  the 
data  acquisition  and  input  process.  The  terrain  editor  we  have  allows  us  to  use  the 
barrier  handbook  and  a  site  map  to  digitize  the  LLNL  site  and  specified  barrier 
attributes  in  about  four  days.  I  might  just  mention  that  this  site  is  about  one  square 
mile,  and  includes  14  miles  of  road,  about  five  miles  of  fence,  500  exterior  buildings  and 
one  building  interior.  Using  the  Army  master  PH/PK  data  base  we  were  able  to  define 
weapon  target  relationships  in  about  three  hours.  This  included  three  weapon  types  and 
eight  different  target  types.  Using  the  barrier  handbook  and  time  distance  studies  we 
were  able,  using  the  scenario  editor,  to  define  human  performance  scenarios  in  about 
one  day.  It  doesn’t  take  a  long  time  to  develop  a  data  model,  and  the  new  editors  will 
be  more  advanced  than  the  group  we  have  right  now. 

Perhaps  one  of  the  most  important  questions  is,  how  can  the  model  be  used?  We 
envision  the  model  being  used  for  training  in  command  control  communication  tactics. 
We  have  taken  a  yard  sergeant  who  is  responsible  for  keeping  the  intruders  out  of  the 
laboratory,  and  a  communications  sergeant  in  the  communications  center,  and  let  them 
operate  the  simulator.  They  are  located  in  separate  rooms,  and  communicate  using  their 
regular  hand  held  radios.  The  only  information  they  have  is  on  their  monitor  screen, 
and  the  only  information  on  the  screen  is  of  the  forces  and  the  resources  that  they 
control.  So  he  doesn’t  know  what  this  guy’s  forces  are  seeing,  and  this  guy  doesn’t  know 
what  his  forces  are  seeing.  The  only  way  they  can  find  out  what  is  going  on  is  through 
the  radio  communications.  The  players  report  what’s  occurring  on  their  screen  so  they 
can  track  and  follow  the  intruders  as  they  go  through  the  laboratory. 

This  type  of  exercise  has  turned  out  to  be  a  very  effective  training  tool,  because  the 
model  runs  in  real  time.  There  are  events  that  will  overtake  you  if  you  don’t  make  a 
decision  now,  so  you  can't  wait  around  and  think  about  it.  When  an  event  happens,  you 
have  got  to  decide  how  that’s  going  to  impact  your  team,  make  a  decision  for  them,  and 
get  them  moving  in  another  direction  or  taking  cover  or  doing  something  else,  or  they 
are  going  to  get  wiped  out. 


Human  Performance  skill  levels  are  based  on  the 
performance  distribution  data. 
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Random  draw  determines  actual 
performance  for  each  event 


This  type  of  exercise  also  provides  good  training  in  terms  of  the  communication, 
and  command  and  control.  In  terms  of  communication,  they  have  to  be  very  precise, 
and  players  learn  to  be  very  precise  on  the  radio,  to  say  very  quickly  what's  going  on 
and  how  the  others  should  respond  to  the  events  that  are  occurring  on  the  screen. 

The  neat  thing  about  this  type  of  exercise  is  that  it  has  minimal  data  requirements, 
and  it  works  well  with  data  estimates.  You  don't  have  to  be  precise  about  the  site,  or 
all  of  the  human  performance  skills,  because  you  really  are  trying  to  train  these  guys  on 
how  to  respond  to  certain  situations.  The  training  allows  the  students  to  practice 
essential  decision  making  skills. 

Another  significant  use  of  SEES  is  that  it  allows  you  to  design  your  site.  You 
modify  your  site  design  by  using  the  terrain  editor.  You  can  put  in  whatever  site 
characteristics  you  want,  and  then  run  the  simulation  against  it.  You  can  check  such 
things  as  line  of  sight.  This  helps  you  evaluate  site  changes  and  check  for  blind  spots  in 
your  surveillance.  You  can  look  at  various  visual  barriers  and  assess  who  that  cover 
really  benefits:  Does  it  benefit  your  PSOs  or  does  it  benefit  the  intruders?  You  can 
look  at  movement  paths,  and  how  the  movement  is  going  to  be  channeled  throughout  the 
laboratory.  You  can  look  at  the  design  obstacles  such  as  the  ground  surfaces,  and  see 
how  they  will  affect  movement.  This  kind  of  use  requires  detailed  site  data  on  the 
buildings,  doors,  walls  and  barriers  for  accurate  site  security  system  desig.1.  Once  you 
have  the  site  entered  into  SEES  prototyping,  new  ideas  become  relatively  easy. 

This  is  one  of  the  primary  things  that  we  built  the  model  for:  testing  of  detection, 
delay,  response,  and  neutralization  of  the  intruder  force.  One  of  the  things  that  is 
amazing  to  me  is  the  high  cost  of  force-on-force  exercises.  They  cost  $40,000  to  $50,000 
apiece,  and  the  only  data  they  got  out  of  them  is  who  won  or  who  lost,  and  that  might 
depend  on  a  secretary  who  happened  to  see  the  intruders  come  in  the  outside  fence, 
called  in  the  alarm,  and  the  guards  were  waiting  for  the  intruders.  You  know,  strange 
things  happen  in  these  force-on-force  exercises;  $40,000  to  $50,000  are  spent,  and  very 
little  benefit  is  gotten  out  of  it.  By  using  SEES  and  planning  the  exercise  (having  a  real 
plan),  you  can  eliminate  a  lot  of  these  strange  happenings. 

Another  thing  the  plan  does  for  you  is  it  allows  you  to  play  it  on  simulation  as  a 
pre-exercise  briefing  for  your  observers  and  your  referees.  In  this  way  they  know 
what’s  going  to  happen,  and.  they  know  where  and  when  the  action  is  going  to  take 
place.  In  this  way  they  can  develop  the  data  collection  procedures  that  they  need  to 
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Utilities  are  provided  to  simplify  the  data 
acquisition  and  input  process. 


•  Terrain  editor,  using  Barrier  handbook,  site  map: 

*  Digitized  LLNL  site  from  map  and  specified  attributes  in  4  days 

-  One  square  mile,  14  miles  of  roads,  Smiles  of  fence 

-  500  exterior  buildings,  1  building  Interior. 

•  PK  editor ,  using  U.S.  Army  master  PH  /  PK  data  base  : 

*  Defined  weapon  -  target  curves  In  three  hours. 

•  Three  weapons  types-  eight  different  targets  types 

•  Scenario  editor,  using  Barrier  hand  book.  Time  dlstancs  studies: 

*  Defined  all  human  performance  and  vehicle  attributes  In  one 
day. 

-  Five  human  types,  three  vahlcle  types. 


. .  j 

Inputting  the  required  data  into  SEES  is  very  easy  and  relatively  fast 
to  do.  Most  of  the  data  requirements  are  provided  with  the  model's 
sample  scenario  as  defaults.  The  user  can  modify  any  of  the  data  as  they 
wish  and  the  editor  utilities  provided  with  SEES  ailow  the  user  to  make 
the  changes  efficiently. 

The  Terrain  editor  reads  the  Terrain  elevation  data  base,  and  set  up 
the  grid  coordinates.  The  user  can  either  by  freehand  create  buildings, 
roads  and  other  objects,  or  digitize  them  from  a  map  placed  on  the 
Tektronix  graph  tablet.  As  each  object  is  created  it  is  given  a  identity 
number  and  a  object  type  which  defines  its  attributes.  The  user  can 
specify  the  attributes  of  each  object  type  or  use  the  default  values  from 
the  data  base. 

The  PH  /  PK  editor  allows  the  user  to  define  the  probability  of  hit,  and 
probability  of  kill  for  each  weapon  target  pair  he  wishes  to  model. 
Default  curves  are  provided  by  a  master  data  base  for  most  standard 
systems. 

The  Scenario  editor  allows  the  user  to  define  for  each  system  in  the 
simulation;  the  general  platform  attributes,  Acquisition  characteristics, 
Combat  from  cover  characteristics,  Carrier  capabilities,  Engineer 
capabilities,  Degradation  effects,  and  Mobility  parameters.  Weapon 
systems  are  also  defined  as  well  their  target  priority. 

The  Scenario  editor  also  allows  the  user  to  modify  and  control  the 
performance  parameters  that  determine  the  update  frequencies  for  each 
event  process.  In  addition  the  report  frequency  and  output  data  is 
defined  here  by  the  user. 
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SEES  can  be  used  for 
Training:  Command,  Control,  Communications  and  Tactics 


>  Leadership 


>  Planning  £  Tactics 


Containment 

Sergeant 


Blue  Team 


Commit! 

Center 


Yard 

Sergeant 


*  Minimal  data  requirements.  Works  wall  with  data  estimates. 


liAe 
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SEES  can  also  be  used  for  training  command,  control, 
communications  and  tactics,  in  this  application  team  members  work 
together  to  defeat  a  common  enemy.  Each  member  has  a  mission  and 
a  set  of  forces  or  resources  he  controls. 

Interacting  with  the  simulation  in  real  time,  each  member  makes 
decisions  based  on  the  information  he  receives  from  his  screen  and 
an  external  radio  linking  the  team  members  together.  Each  screen 
provides  only  the  information  that  has  been  obtained  by  the  forces  or 
resources  controlled  by  that  workstation.  Thus  each  member  must 
communicate  with  the  other  team  members  In  order  to  know  what  is 
happening  in  their  area .  One  team  member  can  be  the  commander 
providing  direction  and  commands  to  the  other  team  members. 

The  SEES  simulation  advances  time  continuously,  providing  a 
sense  of  urgency  and  stress  which  gives  the  training  a  degree  of 
realism. 

Data  requirements  for  training  applications  are  in  most  cases  are 
minimal  where  reasonable  estimates  or  default  values  can  be  used. 
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collect  the  information  that  they  actually  want.  When  the  force-on-force  exercise  is 
over,  they  can  come  back  and  do  the  replay  of  the  data  analysis,  do  the  statistics  and 
sensitivity  studies,  and  really  begin  to  understand  more  than  just  the  final  outcome  of 
the  force  on  force  exercise.  They  can  understand  a  lot  of  the  details  of  what  led  to  the 


outcomes. 


SEES  can  also  be  used  for  site  security  analysis  and  evaluation.  This  is  one  of  the 
powers  of  Janus,  that  has  come  through  to  SEES.  The  system  allows  you  to  use  a  team 
of  experts  working  together.  Each  member  of  the  team  works  off  the  same 
information,  and  they  try  to  protect  the  facility.  Likewise,  you  have  another  team  of 
experts  working  to  break  into  the  facility. 


Let  me  go  back  and  review  a  little  bit  for  you  the  concepts  that  we  are  using  in 
developing  the  model.  First  thing  we  did  was  modify  the  Janus  combat  model  to 
provide  an  operational  prototype.  We  are  maintaining  this  prototype  and  updating  it  as 
we  progress  with  the  model  development.  We  use  the  prototype  to  develop  and  test 
some  of  the  requirements  for  the  actual  model  that  we  are  building,  and  we  use  it.  of 
course,  for  demonstrations  and  immediate  user  application.  We  also  use  it  to  develop 
ideas,  and  to  gain  insight  into  what  some  of  the  user  interface  problems  are.  We  bring 
in  the  PSOs,  and  train  them  on  the  system.  It  takes  them  about  four  days  to  get 
adjusted  to  the  model,  and  then  they're  off  and  running  on  it.  We  get  a  lot  of  valuable 
feedback  on  what's  easy  to  do  and  what’s  hard  to  do.  We  are  able  to  adapt  the  total 
system,  the  menu  and  the  graphic  interface,  to  meet  their  needs. 


For  the  longer  term  we  are  designing  a  model  using  advanced  software  engineering 
methods.  This  model  is  going  to  be  numbered  2.0  and  up.  It’s  a  model  where  we  will 
have  full  documentation  which  enhances  maintenance  and  verification.  Another 


important  feature  is  the  extensibility  of  the  model.  We  are  going  to  be  able  to  expand 
this  model  as  necessary.  Its  object  oriented  design  will  allow  for  easy  modification  and 
extensibility.  I  am  convinced  that  object  oriented  analysis  and  design  is  the  only  way  to 
do  future  modeling.  I  didn't  think  so  a  couple  years  ago,  but  I  am  convinced  of  it  now. 
You  really  understand  the  problem  when  you  are  done,  and  to  me  that’s  the  key  of  the 
model  The  other  aspect  of  it  is  you  do  all  the  work  up  front.  You  think  it  out  before 
you  ever  go  to  the  computer  or  put  a  word  or  a  algorithm  on  a  piece  of  paper.  You 
understand  what  the  data  are,  what  the  needs  are,  what  the  requirements  are,  what  it 


takes  to  do  the  job.  You  get  all  those  issues  resolved  before  you  go  in  and  start  coding. 
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We  plan  on  developing  the  new  model  in  Ada.  Using  this  language,  we  hope  will 
provide  a  reliable  and  portable  model.  I  firmly  believe  that  Ada  is  going  to  advance 
rapidly.  The  compilers  and  the  speed  of  operation  of  Ada  is  going  to  advance  very 
rapidly  as  the  years  go  by,  and  it’s  going  to  advance  in  the  same  manner  as  all  the 
hardware  has  advanced  over  the  last  few  years. 

SEES  (the  1.1  which  is  our  prototype)  models  most  of  the  key  processes  that  we  feel 
are  going  to  be  necessary  for  understanding  the  requirements;  the  model  terrain 
features  such  as  fields,  roads,  fences,  buildings,  walls  and  doors.  It  also  models  human 
sprinting  and  walking  (just  two  speeds),  the  detecting  of  targets  and  shooting,  and 
assessment  of  those  shots.  Like  Janus,  it  has  item-item  resolution,  i.e.,  one  soldier  is  able 
to  shoot  just  one  target  individual.  If  he  gets  a  kill  and  he  has  another  acquisition,  he 
must  first  have  enough  ammunition,  and  second,  have  the  time  to  swing  his  rifle  around 
and  take  aim.  If  these  conditions  are  met.  he  can  engage  the  second  target. 

SEES  1.1  has  also  given  us  experience  modeling  time  delay  penetration  through 
various  barriers  and  doors.  We  assume  intruders  can  breach  the  doors.  We  know  from 
the  barrier  handbook  put  out  by  DOE  how  long  it  takes  based  upon  the  type  of  door.  In 
the  model  we  make  the  intruder  wait  that  length  of  time  at  the  door.  When  the  door 
opens,  he  is  able  to  go  right  through.  We  can  do  the  same  thing  with  walls  and  fences. 
In  SEES  1.1  we  also  model  mounting  and  dismounting  of  vehicles.  This  is  another 
attribute  that  we  got  directly  from  Janus.  Having  Janus  put  us  a  leg  up  on  the  whole 
modeling  graphics  process  in  a  very  rapid  way. 

For  SEES  2.0  we  are  going  to  have  sequential  test  planning,  that  is.  the  units  are 
going  to  be  able  to  perform  certain  tasks  that  are  defined  in  the  plan  as  put  in  by  the 
player.  The  units  will  have  to  carry  tools  and  use  those  tools  in  penetrating  barriers. 
We  are  going  to  have  full  cover  and  concealment  of  all  objects;  that  is,  some  objects  will 
provide  you  with  just  concealment  and  some  will  provide  you  with  cover,  and  it  will  be 
dependent  upon  the  weapon  type  that  is  being  fired  at  you.  Right  now  the  prototype 
model  is  limited  to  just  a  single  floor.  In  SEES  2.0  we  will  have  multiple  floor  buildings 
where  the  units  can  travel  from  floor  to  floor.  We  will  have  three  posture  modes: 
prone,  crouch,  and  stand;  four  movement  modes;  and  two  forms  of  firing:  suppression 
and  directed  fire.  We  will  have  units  carry  items  that  they  can  use  such  as  tools, 
weapons  and  special  materials.  As  part  of  this  feature  we  will  have  various  skills  levels 
in  these  three  areas.  We  will  also  include  a  fatigue  and  rest  model. 
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SEES  can  be  used  for 
Site  Security  System  Design  and  Testing 


•  Site  Design:  Lins  of  sight.  Cover,  Movement  Piths 

•  Delay  Design:  Movement  surfaces,  Penetration  Vulnerabilities. 


*  Requires  detailed  site  data  on  buildings,  doors,  wails,  and  barriers  for 
accurate  site  security  system  design.  Minimal  data  for  prototyping  Ideas. 


There  are  several  applications  that  SEES  is  being  designed  for.  This 
slide  shows  r.ow  SEES  can  be  used  for  Site  Security  System  Design 
and  Testing.  A  single  user  has  prepared  a  simulation  scenario  to  test 
the  security  safeguards  of  the  site.  He  modifies  any  aspect  of  the  site 
including  buildings,  doors,  sensors,  and  fences  using  the  terrain  editor. 
He  then  can  run  the  simulation  against  the  modified  site  looking  for 
improvement  In  detection,  delay,  response  and  neutralization. 

This  process  can  be  repeated  varying  either  the  scenario  or  the  site 
characteristics  or  to  develop  a  statistical  sample  for  a  given  scenario 
and  site  version. 

Data  requirements  for  the  site  can  vary  from  minimal  effort  to 
maximum  effort  depending  on  the  application.  For  prototyping  ideas 
only  a  minimal  effort  is  needed.  For  site  design  or  comprehensive 
studies  considerable  research  and  data  collection  may  be  required.  The 
SEES  model  allows  the  user  to  run  the  model  with  the  minimal  amount 
of  data  or  to  put  In  as  much  detail  as  the  user  thinks  Is  needed. 
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SEES  can  be  used  for  Planning 
and  Analysis  of  Force  on  Force  Field  Exercises* 


Common  Goals 
for  tasting  of 
D«  taction 
Daisy 
Rasponsa 
and 

Nautrallzation 


•  Rad  taam  (laid  axarcisa  plan 

•  Obsarvar  &  Rafaraa  brlaflng  tool 

•  Data  coiiactlon  procaduraa 


•  Raplay  &  data  analysis 

•  Statistics  &  sensitivity  studies 

•  Simulation 


*  Data  requirements  can  vary  greatly  between  planning  and  analysis. 


SEES  has  been  specifically  designed  to  provide  a  tool  for 
planning  and  analysis  of  Force  on  Force  field  exercises.  The 
adversary  team  uses  SEES  to  plan  the  intrusion  onto  the  site.  The 
observers  and  referees  use  the  simulation  plan  to  determine 
location,  timing,  and  types  of  events  to  be  expected.  The  analyst 
uses  the  simulation  to  determine  the  data  collection  procedures, 
for  data  analysis,  and  to  determine  statistical  distributions.  The 
Idea  is  to  understand  the  field  exercise  and  develop  a  statistical 
sampling  consistent  with  the  fieid  exercise  using  the  simulator. 

input  data  requirements  can  vary  considerably  depending  on 
the  degree  of  detail  required  for  the  analysis.  Because  a  force  on 
force  exercise  is  a  fieid  simulation,  many  of  the  data  details  of  the 
site  can  be  simplified,  as  well  as  many  of  the  human  performance 
processes.  Breaching  a  barrier  with  tools  or  explosives  is  a  good 
example.  Movement  and  acquisition  parameters  that  are  provided 
with  the  model  are  usually  sufficiently  accurate.  Data  representing 
the  MtLES  equipment  and  the  accuracy  of  the  laser  in  registering  a 
kill  or  near  miss  needs  to  be  developed.  Currently  data  simulating 
real  weapons  that  are  provided  with  the  model  are  being  used. 


SEES  can  be  used  for 
Site  Security  Analysis  and  Evaluation* 


•  CrMttv*  ttudl—  through  competition. 

•  Different  expertl*#  applied  simultaneously. 

•  Integrated  studies  of  alt  aspects  of  physical  security. 


*  Analysis  and  evaluation  requires  accurate  data. 
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SEES  can  also  be  used  for  Site  Security  Analysis  and  Evaluation  by 
two  opposing  teams.  SEES  provides  a  team  approach  to  problem 
solving  where  several  security  experts  devise  ways  to  defeat  a  site's 
security,  and  another  team  of  security  experts  devise  ways  to  defend 
the  site  against  the  threat  Hero  the  players  work  together  side  by 
side,  sharing  the  control  of  the  simulation  as  well  as  ideas  to  defeat 
the  enemy.  The  simulation  advances  in  real  time  as  each  team  reacts 
to  the  moves  and  counter  moves  of  the  other  team. 

Once  a  scenario  has  been  developed  through  many  Interactive 
simulations,  a  statistical  study  can  be  done  to  develop  a  distribution  of 
possible  outcomes. 

Data  requirement  for  analysis  and  evaluation  requires  that 
considerable  effort  be  devoted  to  the  development  and  collection  of 
data.  This  is  especially  important  for  the  players  to  exercise  their 
expertise  in  the  various  areas.  The  editors  make  the  Input  of  the  data 
once  collected,  very  quick  and  easy. 
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The  SEES  development  plan  provides  a  prototype  ii=l 
for  Now  and  a  engineered  model  for  the  future.  1 


•  Modify  th«  Janus  Combat  Modal  to  provlda  an  operational 
proto ty pa  during  all  stages  of  davaiopmant  SEES  1.+ 


Oavalop  and  fast  raquiramants. 
Demonstrations  and  User  Application. 


•  Design  a  modal  with  a  long  future  using  advanced  Software 
Engineering  Methods.  SEES  Z*  la  a  modal  where 


Full  documentation  enhances  maintenance  and 
verification 

Object  oriented  analysis  and  design  allows  easy 
modification. 

afaj^ementatlon  provides  a  reliable  and  portable 


■rue* 


SEES  is  being  developed  on  two  paths  simultaneously.  We  f|*nt 
wanted  to  have  a  operating  prototype  as  early  In  Jie  project  schedule 
as  possible  so  that  the  LLNL  security  personnel  could  test  the  model 
and  provide  additional  Input  for  the  user  interface  and  the  modeling 
process.  Janus,  a  modei  which  simulates  mechanized  combat,  was 
modified  to  accept  an  urban  terrain  and  human  entities  and  proved  to 
be  an  excellent  prototype.  It  was  in  the  use  of  the  prototype  and 
feedback  from  the  PSO's  that  enabled  us  to  develop  the  User's 
Requirements.  The  prototype  has  also  been  used  as  a  demonstration 
vehicle  to  gain  interest  and  support  for  the  project  in  terms  of  funding, 
test  data,  and  expert  advice  from  various  government  agencies  in  the 
many  areas  we  are  modeling.  The  prototype  has  also  been  used  in  the 
first  attempt  to  validate  parts  of  the  modei  by  simulation  of  an  actual 
force  on  force  field  exercise. 

The  second  path  is  to  design  SEES  from  the  ground  up,  using  the 
knowledge  and  experience  which  developed  Janus,  in  conjunction 
with  advanced  software  engineering  methods.  This  provides  a 
modeling  process  that  is  documented  at  each  step,  where 
implementation  of  a  concept  is  linked  directly  to  the  requirements,  and 
the  maintenance  and  modifiability  of  the  code  Is  not  dependent  upon  a 
specific  programmer  or  manager.  The  goal  is  to  produce  a  reliable, 
efficient,  understandable,  maintainable,  modifiable,  portable  computer 
code,  lasting  well  in*o  the  21st  century. 


SEES  1.1  models  most  key  processes  of  site 
security  including  neutralization 


Models  terrain  features  suet)  as  fields  and  roads, 
fences,  buildings,  walls  and  doors. 


Models  human  sprinting  and  walking, 
detecting  targets,  shooting  and  assessment, 
engaging  from  cover  and  direct  firs  suppression. 


Models  time  delay  penetration  of  doors,  walls  and  fences. 
Models  mounting  and  dismounting  of  vehicles. 


■/La** 


The  current  version  of  the  prototype,  SEES  1.1,  models  most  key 
processes  of  site  security  Including  neutralization. 

Simple  terrain  features  such  as  fields  and  roads  are  modeled.  Fences, 
wails,  and  doors  which  are  also  breachable  barriers  are  also  modeled. 
Breaching  is  modeled  as  a  time  delay  based  on  the  data  for  each  barrier 
type  from  the  Barrier  Technology  Handbook,  Sand77-0777  rev,  1987. 

Human  entities  move  at  two  speeds  representing  sprinting  and 
walking.  Acquisition  of  targets  is  based  on  the  U.S.  Army  ASARS  model 
where  each  human  entity  will  detect  a  target  after  a  calculated  delay  time 
from  first  having  line  of  sight  The  delay  time  Is  dependent  on  the  target 
size,  the  distance  to  the  target,  and  if  it  Is  moving  or  shooting.  Line  of 
sight  must  be  maintained  during  the  acquisition  process.  Line  of  sight 
can  be  blocked  by  the  terrain  elevation,  buildings,  wails  and  doors  and 
any  other  solid  terrain  object. 

After  acquiring  one  or  more  enemy  units,  one  is  selected  to  be  targeted 
based  on  priority  criteria.  The  shooter  aims  and  fires  at  the  target.  The 
shot  Is  assessed  for  a  hit  based  on  a  random  draw  against  the  probability 
of  hit  obtained  from  U.S.  Army  weapon's  effect  data.  Given  a  hit  the  target 
is  assessed  for  a  kill  with  another  random  draw.  For  each  weapon  target 
pair  there  are  PH  curves  as  a  function  of  range,  and  PK  curves 
representing  conditions  or  states  of  the  shooter  and  target,  if  the  target  is 
killed  the  shooter  selects  another  acquired  target,  or  else  the  shooter 
re-aims  at  the  current  target  and  shoots  again.  He  reloads  from  his 
assigned  ammunition  allotment  when  his  gun  is  empty. 
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SEES  2.0  will  have  alt  the  capabilities  of  SEES  1.1  plus 


•  Sequential  task  planning 

•  Cover  and  concealment 

•  Penetration  with  tools. 

•  Multiple  floor  buildings 

•  Fatigue  and  rest  model 

•  Thrse  posture  modes  -  prone,  croud  i, 

•  Four  movement  modes  -  sprint,  walk,  crawl,  & 

•  Suppression  and  Suppressive  direct  fire 

•  Carry  items  -  tools,  weapons,  special  materials  I 

•  Skills  -  Marksmanship,  endurance,  &  penetration  I 

J 


During  this  current  year  (FY  88)  the  design  of  SEES  2.0  will  be 
completed.  FY  89  is  the  year  that  SEES  2.0  will  be  coded  and 
distributed  to  those  facilities  funded  by  DOE  to  have  the  model.  SEES 
2.0  will  be  designed  for  easy  maintenance  and  modification  and  will 
be  well  documented. 

In  addition  to  the  considerable  Capabilities  of  the  prototype,  SEES 
2.0  will  also  Include  the  following: 

Sequential  task  planning  that  allows  a  sequence  of  tasks,  such  as 
pick  up  Item,  throw  item,  drop  Item,  climb,  return  fire,  cover  fire, 
target  object,  indirect  fire,  change  view,  change  gas  mask,  penetrate, 
change  posture,  and  change  speed,  to  be  planned  for  each  human 
entity  in  the  simulation  at  each  movement  node.  Each  human  will 
carry  out  these  tasks  within  five  degrees  of  skill  leva.'  determined  by 
the  distribution  of  measured  performance  tests. 

Cover  and  concealment  are  also  modeled  with  the  degree  of  cover 
as  a  function  of  weapon  type.  The  time  to  penetrate  a  barrier  will 
depend  on  the  tools  the  human  is  carrying.  The  human's  movement 
and  endurance  will  be  affected  by  the  weight  of  the  equipment  he  Is 
carrying.  Fatigue  will  be  modeled  as  well  as  rest  to  cure  fatigue. 

Buildings  will  be  modeled  with  multiple  floors  such  that  the  human 
can  move  and  engage  through  the  entire  building. 

Humans  will  be  able  to  move  at  three  speeds  as  well  as  climb  and 
bridge  barriers,  and  change  posture. 


SEES  urban  terrain  will  model  buildings,  streets 
foliage,  fences,  tights,  and  sensors. 


SEES  Project  Ptan  FY89 


•  SEES  2.0  System 

January  89 
March  89 
March  89 
May  89 
July  89 
July  89 
August  89 
September  89 


*  SEES  terrain  editor 

*  SEES  symbols  editor 

*  SEES  PH/PK  editor 

*  SEES  characteristic  editor 

*  SEES  scenario  editor 

*  SEES  algorithm  editor 

*  SEES  simulator 

•  Research*  Human  Acquisition 


In  fiscal  year  89  the  simulator  and  all  of  the  required  support 
systems  will  be  programmed  in  Ada.  The  goal  here  is  to  have  a 
system  that  is  easy  to  use,  with  data  files  available  for  the  user  to 
adapt  or  modify  to  meet  his/her  study  requirements. 

The  model  will  also  be  fully  documented  with  a  user's  manual, 
an  algorithm  manual  that  describes  all  of  the  algorithms  used  In  the 
model. 

A  major  portion  of  the  plan  is  to  do  research  on  parts  of  the 
model  that  need  improvement  or  needs  to  be  further  refined  or 
validated  with  additional  data  and  tests.  For  FY89  the  research 
topic  is  the  Acquisition  Model  which  needs  to  be  expanded  to  cover 
various  types  of  sensors  and  detectors.  Also  the  current  model  was 
not  designed  or  tested  for  humans  In  close  contact  and  needs  to  be 
refined  and  tested. 
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SEES  Project  Plan  FY90 


•  SEES  3.0  System 

*  Third  side  •  Site  staff 

*  Insider  Modal 

*  Prototype  Sensor  -  Alarm  Modal 

*  Naw  Acquisition  Modal 

•  SEES  Validation  Plan 

•  Research  -  Conditional  Planning 
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The  SEES  project  plan  for  1990  Is  to  develop  and  distribute  the 
SEES  3.0  system  of  codes.  For  SEES  3.0,  the  following  will  be 
added. 

The  staff  of  a  site  can  be  a  important  factor  if  combat  between 
a  group  of  terrorists  and  the  security  force  occurs.  A  third  side  in 
the  simulation  will  be  added  to  represent  the  site  staff.  They  will 
be  controllable  with  plans  in  the  same  manner  as  the  other  two 
sides.  They  can  be  hostile,  neutral,  or  partisan  to  either  the 
security  force  or  the  Intruders. 

In  addition  to  the  third  side,  active  Insiders  will  be  added  to 
the  model.  The  active  insiders  may  consist  of  more  than  one 
human,  and  can  be  masked  as  either  part  of  the  site  staff  or  the 
security  force. 

Also  the  plans  Includes  the  development  of  a  prototype 
sensor  and  aiarm  model.  Various  types  of  sensors,  In  varying 
combinations  will  be  modeled.  The  alarm  model  will  include  the 
sensors  In  combinations  and  a  logic  method  for  an  aiarm  such 
that  the  user  can  define  the  response  required,  and  balance  the 
rate  of  false  alarms  with  the  sensitivity  of  detection.  Tamper 
alarms  will  also  be  modeled. 

An  important  task  for  this  year  is  the  development  of  an 
overall  validation  plan  for  the  complete  model.  The  validation  of 
the  model  will  first  be  done  on  each  modular  process,  and  then 
for  the  entire  Integrated  model. 
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Well,  you  might  ask  when  is  all  this  going  to  get  done?  The  figure  shows  our  plan 
for  ’89.  Our  current  outside  funding  is  not  sufficient  to  carry  out  this  plan,  so  the 
laboratory  is  going  to  pick  up  the  difference  because  they  are  interested  in  seeing  this 
happen.  We  should  be  able  to  complete  a  number  of  the  essential  editors  this  year,  and 
we  will  start  bringing  them  on  line  as  they  become  available.  We  are  going  to  have  an 
algorithm  editor  that  allows  the  user  to  vary  the  parameters  of  each  and  every  algorithm 
in  the  model.  There  will  be  no  data  inside  the  model. 

The  SEES  simulator  is  due  in  August  of  ’89,  arid  like  I  said,  our  research  project  for 
the  year  is  the  human  acquisition  model  which  we  hope  to  have  completed  sometime  in 
September. 

In  terms  of  planning  for  the  future,  we  are  going  to  develop  an  insider  model. 
There  will  be  people  that  work  against  the  existing  system  where  they  bring  in  the 
wrong  people,  or  the  intruders  bring  in  someone,  or  are  able  to  bribe  someone  or  coerce 
someone  to  open  doors  for  them,  or  they  get  someone  inside  that  can  actually  attack  the 
PSOs  and  the  site  staff. 

In  summary.  SEES  is  a  versatile  state  of  the  art  computer  physical  security  model 
that  allows  many  individuals  to  work  the  model  in  a  team  situation.  SEES  models  the 
physics  of  events  and  is  driven  by  measured  field  data.  It  has  been  tested  and  compared 
against  field  exercises,  and  is  being  developed  with  advanced  software  engineering 
methods. 
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SEES  is  a  computer  model  that  provides  a  means  for 
experts  in  physical  security  to  evaluate  and  test  the  security 
of  a  site  as  well  es  train  the  personnel  responsible  for  the 
protection  of  the  site.  The  model  is  designed  fcr  those  who 
are  experts  in  neutralization  tactics,  and  facility  security 
design  but  novices  with  computer  systems.  SEES  human  - 
machine  interface  can  be  operated  efficiently  with  only  four 
days  of  practice,  and  all  data  files  can  be  easily  modified  for 
the  user's  purpose. 

A  primary  requirement  of  SEES  is  that  the  algorithms 
used  in  the  model  have  a  firm  basis  In  physics,  and  are 
linked  to  the  real  world  by  measured  field  data.  That  Is  all 
parameters  are  obtained  from  actual  performance  tests, 
physical  experiments,  and  field  exercises,  it  is  by  formulation 
of  the  algorithms  in  terms  of  real  world  experience  that  we 
are  sure  of  being  able  to  validate  the  model. 

SEES  is  being  designed  with  advanced  Software 
Engineering  Methods  that  wil!  make  the  model  easy  to 
maintain,  modify,  and  document  We  expect  SEES  to  have  a 
long  extended  life  cycle  lasting  well  into  the  21  century. 
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AFTERNOON  SESSION 
130  P.M. 

MR.  BANKS:  I’ll  just  share  with  you  quickly  some  observations  before  we 
introduce  the  next  speaker. 

During  lunch  and  just  listening  to  some  of  the  conversations  in  the  hall,  it  appears 
to  me  that  we  have  several  groups  in  this  audience.  We  have  a  group  of  people  that  are 
operations  research  oriented  model  builders.  I  also  noted  with  some  pleasure  that  we 
have  several  physicists,  who  have  a  lot  of  experience  in  modeling  physical  phenomena, 
and  we  also  have  a  number  of  psychologists  and  physiologists  who  are  very  much 
involved  in  performance  measurement-both  from  a  behavioral  point  of  view  as  well  as 
a  physiological  perspective. 

I  think  when  you  put  those  four  or  five  groups  of  people  together  and  you  get  them 
to  focus  on  a  common  issue,  the  sparks  begin  to  fly  in  terms  of  creative  ideas  and 
insights.  This  is  one  of  the  outcomes  that  we  had  hoped  for.  I  didn’t  expect  it  until  the 
second  day.  but  I  am  starting  to  see  little  creative  flashes  here  and  there. 
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The  next  speaker  is  Major  Anderson  from  the  United  States  Marine  Corps,  First 
Marine  Division,  who  is  one  of  the  managers  of  the  TWSEAS  combat  simulation  system. 

ADDRESS  BY  MAJOR  WES  ANDERSON.  USMC 

MAJOR  ANDERSON:  I  am  Major  Wes  Anderson.  I  am  OIC  at  TWSEAS.  Camp 
Pendleton.  TWSEAS  stands  for  Tactical  Warfare  Simulation  Evaluation  Analysis 
System,  as  shown  in  the  first  figure.  This  presentation  is  the  3ame  briefing  1  give  a 
regimental  commander  who  is  not  familiar  with  the  system,  does  not  know  its 
capabilities  or  has  ever  used  it:  but  it's  been  five,  ten  years  ago  since  he  played  with  the 
system. 

The  next  figure  provides  the  premise  that  we  operate  from.  The  closer  we  can 
come  to  simulating  the  real  thing,  then  the  better  training  that  unit  will  have.  When  a 
unit  wants  to  come  out  and  set  up  a  TWSEAS  Command  Post  Exercise  (CPX),  first  thing 
I  do  is  find  out  what  their  objectives  are.  The  system  is  designed  to  help  unit 
commanders  that  want  to  improve  their  staffs'interaction  so  they  make  the  correct 
tactical  decisions  at  the  appropriate  time.  In  TWSEAS  as  in  real  life,  if  you  make  the 
wrong  decision  at  the  wrong  time,  you  and  your  units  are  going  to  suffer  for  it.  What 
is  TWSEAS?  It’s  just  a  computer  aided  command  and  control  simulation  system.  We 
refer  to  our  main  frame  as  Leon,  and  Leon  is  basically  just  a  large  bookkeeper,  and 
that's  it. 

Our  objectives  are  to  increase  the  realisms  in  the  use  of  tactical  exercise  in  terms 
of:  relationships  to  cause  and  effect,  timeline's,  comprehensiveness,  limitation  of 
resources,  impartial  BDA,  assessment,  and  authentic  simulation.  We  do  this  by  setting 
up  a  CPX  landing  force  fighting  an  opposing  force,  and  I’ll  get  into  that  a  little  bit 
later. 

The  advantages  of  TWSEAS: 

o  You  basically  get  to  practice  what  you  are  learning.  When  the  balloon  goes 
up.  hopefully  you  are  able  to  apply  the  tactics,  the  techniques  and  the 
Marine  Corps  doctrine  you  have  practiced  in  TWSEAS. 

-  The  OPFOR  tactics  span  the  'eve Is  of  engagement  from  the  gorilla  type 
environment  all  the  way  up  to  straight  Soviet  doctrine. 
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-  Intelligence  analysis  in  TWSEAS  is  phenomenal.  The  Intel  officers  or 
Intel  sections  are  normally  overwhelmed  with  the  amount  of  information 
they  receive,  and  they  have  a  very  tough  time  interpreting  what  they 
receive,  analyzing  it  and  aiding  their  commander  to  make  the  appropriate 
decision.  There  is  more  information  than  what  they  probably  would  receive 
in  real  life. 

-  TWSEAS  allows  commanders  to  practice  their  maneuvering  and  fire 
support  for  a  particular  TWSEAS  exercise  as  a  precursor  to  an  actual  field 
exerase.  We  have  war  gamed  several  exercise  plans.  We  play  the  plan  out 
and  come  up  with  different  alternatives  to  it.  The  last  time  we  did  this  was 
a  precursor  for  a  "Gallant  Night"  exercise. 

o  We  present  several  different  courses  of  action  and  the  commander  makes  the 
ultimate  decision  as  to  which  one  he  uses. 

o  We  rehearse  the  exercise  plans  on  the  TWSEAS  and  let  the  commander  try 
his  OP  plan  before  actual  execution. 

o  Our  primary  emphasis  is  on  exercising  command  staff  and  shaking  down  the 
command  post  organization.  Some  of  the  CP  units  that  have  come  out  and 
used  TWSEAS.  the  commander  says  "time  out,"  and  we’ll  stop  the  system. 

He  will  reorganize  things  within  his  COC  to  make  sure  the  right  people  are 
speaking  to  the  right  folks. 

o  A  nice  capability  we  have  is  the  option  of  having  a  two-sided  war,  or  force  on 
force.  We  have  not  used  this  capability  because  the  main  emphasis  has  been 
on  CP  staff  training. 

I  would  like  to  make  a  few  comments  regarding  our  upgraded  software  called 
Integrated  Maneuver  Controller  (IMC),  which  Mr.  Lee  Marsh  of  Systems  Exploration. 
Iiux.  has  been  working  on.  In  our  current  system  (MMC)  we  have  two-sided  and  replay 
capabilities.  IMC  will  give  us  a  three  sided  capability.  Any  questions  regarding  the 
three  sided  capability  should  be  referred  to  Lee  Marsh. 
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AUTHENTIC  SIMULATION 
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The  current  MMC  system  gives  us  up  to  256  addressable  units.  Thcue  units  can  go 
from  a  single  man  unit  up  to  a  full  blown  battalion  unit  with  associated  equipment,  or  a 
regiment  unit  if  necessary.  One  of  the  upgrades  in  IMC  will  give  us  600  addressable 
units,  and  at  the  same  time  allow  us  to  have  four  exercises  going  on  simultaneously. 
This  means  we  will  have  increased  the  number  of  units  up  to  a  maximum  of  2400. 


With  our  current  exercise  environment  the  terrain  is  digitized  on  a  game  board 
covering  1200  km  by  1200  km.  and  within  that  area  we  operate  with  100  kilometer 
digitized  square.  The  resolution  goes  down  to  500  meters.  The  things  we  take  into 
consideration  are  elevation,  traffic  activity;  and  that’s  for  foot,  wheeled  or  track 
vehicles  and  the  vegetation.  We  also  handle  weather  and  time  of  day. 

With  the  IMC  upgrade  we  will  still  have  a  1200  by  1200  kilometers  square,  but 
within  that  area  we  will  have  25  separate  areas  of  100  km  by  100  km  and  that  will  be 
digitized,  and  the  resolution  will  be  variable  at  our  option  from  500  meters  down  to  100 
meters.  The  time  of  day  and  weather  in  the  present  system  can  go  from  clear,  all  the 
way  up  to  snow.  The  sun  rises  and  sets  as  I  dictate,  which  is  nice. 

Some  of  the  ground  combat  capabilities  within  the  TWSEAS  syctem  are  listed 
below.  Over  the  years  the  enhancements  have  made  it  a  very  comprehensive  and 
detailed  model. 

Movement  During  training  exercises  your  movement  cross  country  is  in  real 
time.  If  a  unit  is  walking  from  point  A  to  point  B,  and  the  distance  is  four 
kilometers  and  they  are  traveling  on  a  road  at  four  clicks  an  hour,  then  it  will 
take  them  one  hour  game  time,  or  one  hour  of  real  time  to  cover  that  distance. 

Detection.  The  model  includes  line  of  sight  detections,  so  if  you  see  the 
opposing  force,  they  will  show  up  on  your  monitor.  The  detections  are 
predicated  upon  the  digitized  terrain,  troop  posture,  ie.,  is  he  dug  in  and  hard 
to  see.  and  the  size  of  his  unit.  All  these  things  are  taken  into  consideration. 

Engagements.  We  instruct  commanders  to  tell  their  units  which  way  to  face, 
what  formation  to  be  in.  what  type  of  frontage  they  want  them  on,  and  to  give 
them  a  sector  of  fire;  the  same  type  of  information  they  would  give  a  basic 
Marine  Corps  private,  a  rifleman.  If  they  do  not  do  that  and  the  opposing 
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force  gives  those  orders  to  their  particular  units,  the  opposing  forces  are  going 
to  win. 

Casualty  assessment.  It’s  predicated  on  what  we  decide.  Stochastic  effects  are 
used  for  several  smart  weapons,  while  single  shot  probability  of  kill  is  used  for 
more  conventional  weapons. 

LIDS.  The  system  currently  has  the  capability  of  LIDS,  night  vision  goggles, 
and  nignt  intense  finding  devices. 

NATO  xa  NATO  Capability.  On  a  fcrce-on-force  exercise,  we  can  take  both 
OPFOR  weaponry,  put  it  in  landing  force  units  or  NATO  weaponry,  and  put  it 
in  OPFOR  units. 

Barriers.  We  can  emulate  barriers  of  everything  from  a  mine  field  to  a  sensor 
field  to  a  tank  ditch. 

Another  aspect  of  the  ground  combat  is  unrfaca  fire  «ppnrt  We  have  naval  gun 
fire  and  they  will  fire  with  the  appropriate  naval  guns  or  anti-aircraft  weapons.  We  can 
also  call  in  artillery  support,  the  entire  gamut  of  artillery  weaponry  that  is  available  to 
the  Marine  Corps  forces;  mortars;  61  mortars,  81  mortars,  and  on  the  opposing  force’s 
side  122‘s  and  82*s.  We  can  shoot  smoke.  If  you  shoot  smoke  it  decreases  your  line  of 
sight  detections.  It  will  not  slow  down  your  rates  of  movement  but  it  can  hide  you  and 
conceal  you  as  necessary.  When  the  sun  sets,  it  does  get  dark  within  the  system  and 
your  detection  range  decreases  appropriately.  If  you  shoot  illumination  you  can  get  up 
to  80%  of  a  daylight  detection,  which  is  basically  realistic  If  you  want  to  shoot  a  dual 
purpose  conventional  improved  munition,  you  can.  If  you  went  to  shoot  an  ATDC  fuse, 
you  can.  We  have  a  combination  of  shell  fuse  options. 

On  the  air  side,  TWSEAS  does  have  the  air-to-air  war  and  airborne  early  warning 
capability.  We  can  put  up  an  AWAX  to  detect  OPFOR  aircraft  coming  in,  and  they  can 
do  the  same  thing.  You  can  call  in  fighter  support  and  cap  a  section  to  protect  the 
particular  area  you  are  fighting  in.  The  aircraft  in  your  caps  will  engage  OPFOR 
aircraft  and  the  OPFOR  aircraft  will  do  the  same  thing.  The  damage  assessment  that 
goes  along  with  it  is  predicated  upon  the  weaponry  that  the  aircraft  are  carrying. 
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TWSEAS  has  the  capability  of  flying  deep  air-to-ground  missions  to  provide  close 
air  support  of  the  ground  forces.  Damage  assessment  is  provided  both  for  the  air  to 
ground  and  for  the  surface  fire  support  as  in  real  life.  If  you  call  in  supporting  arms 
very  close  to  your  position  or  on  top  of  your  position,  you  will  take  friendly  casualties. 
That  comes  as  a  hell  of  a  shock  to  a  lot  of  commanders,  and  they  can’t  believe  that  some 
of  their  troops  were  killed  within  the  quasi  system  just  because  they  called  an  air  strike 
on  their  position. 

Anti-Air.  TWSEAS  can  simulate  SAMS.  AAA,  ground  based  radar  for  early  warning 
detection,  fighter  air  to  air  support,  airborne  early  warning,  and  TAOC. 

Intelligence,  the  current  system  will  accept  ground  reconnaissance,  as  in  a  recon 
team  sitting  out  there  and  sending  their  reports  back.  We  can  also  get  intel  from 
unattended  ground  sensors,  or  aerial  reconnaissance  missions,  both  photo  and  visual. 
The  new  TWSEAS  system  will  add  an  infrared  (IR)  capability,  and  a  remotely  piloted 
vehicle  (RPV)  simulation.  All  of  these  intel  systems  provide  real  time  information. 

Combat  Service  Support.  Within  TWSEAS  we  track  ammunition,  vehicles  by  type, 
personnel,  number  of  medevacs,  a  supply  dump,  and  convoys.  All  those  things  are  taken 
into  consideration. 

What  makes  TWSEAS  unique  is  that  we  do  the  abip-to-shora  movement  We 
basically  take  a  unit’s  landing  plan,  we  code  it  up.  and  they  do  the  surface  landing 
scheduled  on  call  We  have  the  capability  of  damaging  landing  craft  both  surface  and 
helicopters,  as  a  part  of  the  ship  to  shore  movement.  We  don’t  really  evaluate  the 
landing  plan,  but  we  can  indicate  to  a  unit  where  they  might  have  a  weak  spot  in  their 
plan.  For  instance,  they  may  want  to  load  up  more  material  in  a  Mike  6  landing  craft 
than  it  will  hold.  We  point  out  these  problem  areas. 

Since  I  have  been  at  TWSEAS,  I  have  conducted  over  60  command  post  exercises, 
the  largest  one  being  Marine  Corps  Division  (MEF)  level.  That’s  a  very  time  consuming 
and  very  intricate  operation.  On  the  aviation  side,  I  have  had  a  Marine  Corps  air  wing 
come  down,  and  a  couple  of  different  Marine  Corps  air  groups  as  part  of  a  Marine 
Corps  expedition  and  brigade.  One  of  the  nicest  things  about  the  present  TWSEAS 
set-up,  that's  due  in  part  to  my  boss,  the  Commanding  General  of  the  MEF,  is  that 
TWSEAS  is  (D  not  required  by  any  using  unit  on  base,  and  (2)  there  is  no  evaluation  or 
report  card.  So  units  have  the  opportunity  to  come  out  to  TWSEAS  and  try  their  unit 
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SOPs  with  no  incrimination.  If  they  work,  that’s  super,  if  they  don’t  work,  they  can  go 
back  home  and  revise  their  plan. 

TWSEAS  definitely  simulates  the  decision  execution.  If  a  decision  to  take  a  hill  is 
made,  and  they  fail  to  take  into  account  what  is  located  on  that  hill  (they  have  not  used 
the  proper  fire  support  and  coordination  necessary  to  get  that  hill),  they  lose  a  company 
in  the  process  of  taking  it.  Historically  units  that  have  come  out  to  TWSEAS  ready  to 
fight  their  war  assume  they  are  going  to  fight  against  the  computer,  which  is  not  so. 
They  fight  against  my  intel  officer  and  his  assistants.  My  intel  officer  fights  whatever 
opposing  force  scenario  that  the  unit  has  requested. 

Units  that  come  out  to  use  TWSEAS  go  through  three  separate  distinct  phases. 
First  one  is  "Oh.  my  god,  what  is  that  computer  going  to  do  to  me?“  They  are  very 
much  afraid  of  it.  After  they  go  through  that  phase,  they  decide  that  the  TWSEAS 
complex  is  a  very  large  expensive  Atari  game,  and  they  are  going  to  win  the  $ame  no 
matter  what  it  takes.  And  the  last  and  best  phase  is,  when  they  decide  they  are  going  to 
utilize  the  tactics  they  have  been  taught,  to  utilize  the  fire  support  the  way  it’s  supposed 
to  be.  and  fight  the  war.  they  really  would. 

TWSEAS  is  currently  being  run  on  an  AN/UYK-7  computer.  It  is  an  ntiquated 
machine,  but  very  reliable.  It’s  old,  it’s  semi-slow,  but  it  works.  With  the  latest 
hardware  upgrade  that  I  received  a  month  ago  I  now  have  the  capability  of  going  out 
and  doing  remote  exercises  via  a  modem.  Future  upgrades  include  the  procurement  of  a 
fourth  unit  that  will  be  located  in  Okinawa. 

One  thing  that  TWSEAS  under  the  present  software  configuration  does  not  do,  is 
simulate  human  factors.  The  electrons  never  get  tired,  they’ll  fight  24  hours  a  day. 
they’ll  march  forever,  and  do  whatever  you  dictate.  Lee  Marsh,  at  System  Exploration. 
Inc.  is  setting  up  a  module  that  will  take  some  human  factors  into  consideration.  The 
new  system  is  going  to  be  table  processor  driven,  which  will  provide  us  with  a  lot  of 
flexibility  to  edit  the  tables  as  necessary. 
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ADDRESS  BY  DR.  J.  TERRENCE  KLOPCIC 


DR.  KLOPCIC:  The  purpose  of  this  conference,  as  I  understand  it.  is  to  match 
human  performance  people  with  modeling  people.  First  of  '*1,  I  don’t  think  human 
performance  models  are  that  much  different  than  physical  performance  models.  It 
takes  three  things  to  simulate  human  performance  or  any  technical  phenomena.  First, 
you  have  to  have  some  sort  of  algorithm,  or  data  base,  or  functional  fit  that  is  going  to 
describe  the  human  performance  parameters  we  are  talking  about.  Clearly  here  it’s 
been  things  like  fatigue  or  locomotion  speed,  or  whatever.  It  also  takes  a  match 
between  the  simulation  and  the  algorithm.  The  algorithm  is  going  to  take  some  kind  of 
inputs.  We  just  heard  about  snow  and  cliffs  that  go  up  at  90®.  etc.,  those  are  inputs-<a) 
they  have  to  be  generated  by  the  simulation,  and  (b)  they  have  to  affect  the  algorithm. 
That’s  the  second  thing.  What  you  have  to  have  is  an  interface.  The  outputs  of  the 
algorithm  are  going  to  be  variables.  These  variables  have  to  have  a  place  in  the 
simulation,  and  they  have  to  have  some  sort  of  a  change;  they  have  to  cause  some  sort  of 
change  in  the  output.  Clearly  this  is  motherhood,  and  is  what  we  have  all  been  saying 
right  along. 

What  I  want  to  do  is  try  to  organize  my  talk  on  AURA  (Army  Unit  Resiliency 
Analysis)  based  on  these  three  things,  the  algorithms-how  they  go  in.  how  they  come 
out.  and  the  difference  they  make.  I  think  if  I  can  get  that  idea  across,  then  each  of  us 
in  his  own  little  portion,  be  he  a  human  factors  type  or  a  modeler  type,  can  see  how  the 
various  parts  will  interact  with  his  job. 

With  this  framework  in  mind.  I  am  going  to  start  my  talk  with  a  discussion  of  the 
simulation  portion,  because  things  will  make  a  little  more  sense  if  I  do  that.  I  will  start 
with  AURA,  then  I  will  go  through  a  couple  of  the  human  factors  models.  I  am  under 
the  impression  that  we  are  primarily  interested  here  in  human  factors  and  human 
performance.  So  with  the  exception  of  heat  stress,  which  is  really  a  casualty  producer,  I 
have  left  out  the  casualty  producers  in  AURA  I  haven’t  gone  through  the  chemical  and 
nuclear  effects  at  all,  but  rather  I  will  concentrate  on  those  things  that  degrade  human 
performance. 

I  want  to  show  you  by  describing  AURA  how  these  things  affect  the  output  of 
AURA  and  then  I’ll  describe  some  of  the  algorithms.  AURA  stands  for  the  Army  Unit 
Resiliency  Analysis.  Resiliency  is  the  ability  of  a  military  unit  to  perform  its  mission 
over  time,  including  times  following  hostile  attack.  The  purpose  of  AURA  is  to  describe 


121 


tlie  functioning  of  a  unit.  Functioning  despite  insults  caused  by  hostile  attack.  AURA  is 
the  state  of  the  art  methodology  for  analysis  of  the  unit  to  determine  what  has 
happened  to  its  functioning  capability.  Although  what  happens  to  the  individuals  is 
clearly  important,  it  is  not  the  end  goal.  The  end  goal  of  AURA  is  to  lump  the 
individual  affects  together  to  show  what  happens  to  the  functioning  of  the  military  unit. 

"Unit"  here  refers  to  rather  small  groups.  We  use  AURA  for  company,  battery, 
sometimes  battalion,  but  you  will  see  at  the  level  of  technical  detail  that  gets  built  into 
AURA,  it  would  start  to  get  a  bit  tedious  if  one  went  much  over  a  battalion  size  unit. 
An  important  factor  in  this  discussion  is  what  do  I  mean  by  the  functioning  of  a  unit? 
We  need  to  describe  the  functioning  with  a  measure  of  effectiveness.  I  like  to  think  of 
measures  of  effectiveness  as  falling  into  two  different  types.  One  measure  of 
effectiveness  might  be  something  like  a  rate  or  a  quality;  something  that  is  predefinable. 

For  example,  an  ammunition  company  should  be  able  to  receive  and  warehouse 
2200  short  tons  of  material  a  day  in  a  field  unit  That's  a  rate  or  quality  type  measure 
of  effectiveness.  I  will  judge  the  unit  on  its  ability  to  do  2200  short  tons.  It’s 
predefinable.  I  have  just  defined  it.  Other  examples  are  rounds  per  minute,  trucks 
loaded  per  day,  correct  messages  per  hour,  etc..  This  type  of  measured  effectiveness  is 
most  appropriate  for  a  one-sided  analysis,  a  one-sided  unit.  An  ammunition  company  is 
a  good  example  of  a  unit  that  would  be  analyzed  in  a  one-sided  analysis.  "One-sided” 
means  that  blue  cannot  protect  himself  by  shooting  red  first  in  the  game.  A  priority, 
the  attack  against  blue  is  predetermined.  That  makes  it  a  one-sided  analysis.  Blue  can 
try  to  protect  himself  by  taking  evasive  measures,  but  he  cannot  change  the  incoming. 
There  is  no  inter-reaction  on  the  incoming. 

On  the  other  hand,  most  of  what  we  have  heard  so  far  today,  certainly  Janus  and 
SEES  and  the  rest  of  these  models,  are  what  I  would  call  the  battle  time  type  measures 
of  effectiveness.  They  are  complex  and  indirect  such  things  as  FEBA  movement,  loss 
ratios,  and  momentum  type  criteria,  i.e.,  "did  you  take  that  hill?"  These  are  really  a 
two-sided  type  measure  of  effectiveness,  and  it  requires  a  two-sided  game. 

AURA  is  a  one-sided  game,  therefore,  the  units  that  we  use  AURA  for  are  units  like 
Army  combat  support,  combat  service  support  units.  You  would  not  use  it  for  a  tank 
battalion  engaged  in  combat,  because  you  are  more  interested  in  who  can  hide  behind  a 
hill;  which  does  not  play  in  AURA.  On  the  other  hand,  ammunition  companies  don't 
hide  behind  hills.  Rather,  what’s  important  is  how  much  can  it  take  and  what  can  it 
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recoup.  What  can  it  do  to  modify  the  effects  of  the  damage  in  order  to  get  down  to 
doing  its  job?  What  happens  to  its  rate  of  performance  after  an  attack?  What  this  says 
is  that  AURA  fits  in  a  different  place  in  the  hierarchy  of  war  games.  The  next  figure 
shows  some  of  the  war  games  from  the  Army  model  improvement  program. 

You  will  notice  in  this  little  diagram  that  there  is.  along  with  the  size  of  a  unit,  an 
intrinsic  time  period  that  is  appropriate  for  an  analysis  of  a  unit.  Companies  (even 
battalions)  will  fight  on  the  order  of  hours.  If  you  start  coming  up  to  divisions  or 
corps,  you  start  looking  at  analyses  that  will  run  days,  maybe  into  weeks.  Theaters, 
maybe  more. 

Notice  that  the  time  frame  that  is  appropriate  for  a  combat  company  does  not  hold 
for  a  support  company.  For  an  ammunition  company,  it’s  more  appropriate  to  be 
looking  at  what  it’s  going  to  be  able  to  do  over  days,  because  that  ammunition  company 
will  be  working  in  isolation  for  days.  So  is  a  ship,  probably.  These  support  units  are 
best  described  by  AURA  and  resiliency.  So  AURA  is  not  an  alternative  to  something  like 
Janus.  Actually,  AURA  is  a  compliment  to  Janus,  CORBAM.  CORDIVEM,  VIK,  or  any 
of  the  two-sided  war  games.  AURA  is  in  a  position  to  feed  the  war  game  models 
information  from  combat  service  and  combat  support  units. 

Enough  about  where  it  fits.  As  I  said,  the  purpose  of  AURA  is  to  provide  a  means 
of  evaluating  in  detail  the  effectiveness  of  combat  against  the  performance  of  a  unit, 
against  the  output  of  a  combat  unit,  or  of  a  support  unit,  or  a  combat  unit  in  reserve. 

Another  purpose,  a  methodological  purpose  in  our  building  AURA,  was  to 
amalgamate  in  one  place  the  accepted  state-of-the-art  methodologies.  In  developing 
AURA,  the  Ballistic  Research  Laboratory  really  did  not  so  much  develop  a  new  model  as 
it  did  put  together  in  a  framework  a  number  of  models  that  already  existed,  that  had 
been  developed  by  the  lead  laboratories  in  the  various  areas.  There  are  places  to  go  if 
you  want  conventional  vulnerability  data,  or  if  you  want  nuclear  effects.  There  are 
places  to  go  to  get  them.  What  we  did  in  producing  AURA  was  to  develop  a  framework 
to  tie  these  models  in  to  show  what  happens  to  one-sided  units.  As  a  result,  we  refer  to 
AURA  as  a  family  of  methodologies.  There  is  a  code  called  AURA.  Tied  into  AURA  are 
conventional,  nuclear,  toxic  chemical,  MOPP  degradation,  nuclear  doses,  and  the  data 
from  IDP.  AURA  also  includes  information  on  unit  organization,  what  jobs  they  do,  how 
they  deploy,  what  weapons  would  be  used  against  them,  how  they  repair,  etc.,  etc.. 
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Each  of  the  boxes  in  the  next  figure  represents  at  least  one  (and  in  several  cases 
many)  different  agencies  that  have  produced  the  models  that  they  use  at  the  technical 
level.  Those  models  were  taken  pretty  much  intact  and  swallowed  up  into  the  AURA. 

The  AURA  code  itself  is  a  one-sided  event  simulation.  After  processing  the  inputs, 
the  code  steps  from  event  to  event.  If  the  event  is  a  lethal  event,  i.e.,  some  rounds 
coming  in,  the  model  pops  over  and  grabs  the  appropriate  algorithms  for  analyzing  the 
attack.  If  it  is  a  chemical  attack,  it  starts  laying  chemical  grids  on;  if  it’s  a  nuclear 
attack,  it  runs  through  a  series  of  DNA  environment  calculators;  if  it’s  a  conventional 
attack,  you  use  the  routines  that  were  referred  to  earlier  to  calculate  the  effects.  It  then 
pops  down  and  goes  to  the  next  event. 

The  next  event  is  what  I  call  a  reconstitution;  a  time  at  which  the  smoke  is  cleared 
and  the  commander  can  try  to  get  his  act  back  together.  He  can  try  to  see  how  well  his 
unit  performs.  AURA  then  runs  through  a  series  of  steps. 

First,  it  updates  the  time  dependent  factors.  There  are  a  great  number  of  time 
dependent  effects  such  as  the  progress  of  fatigue  (which  you  have  heard  so  much  about 
here),  or  the  progress  of  nuclear  doses,  which  I’ll  show.  The  code  updates  the  time 
dependent  factors  and  out  of  this  it  comes  up  with  a  set  of  degraded  assets,  a  pool  of 
degraded  assets  for  the  commander  to  use. 

It  then  pops  into  the  allocation  model  which  models  the  smart  commander.  The 
smart  commander  takes  a  look  at  the  assets  he  has,  the  job  that  he  has  to  do.  and  he 
allocates  those  assets  in  such  a  way  as  to  optimize  the  performance  of  his  unit  to  try  to 
get  maximum  output.  It  accumulates  the  statistics  and  makes  any  changes  that  the 
decision  maker  has  caused.  For  example,  if  people  get  assigned  to  new  jobs,  they  get 
redeployed.  At  this  point  the  model  pops  back  into  the  event  and  continues  on  with  the 
battle. 

The  model  runs  on  a  number  of  different  machines,  and  in  about  12  or  14  different 
agencies  including  a  couple  overseas.  We  run  the  model  on  Crays,  we  are  really 
spoiled.  But  it  runs  on  Univac,  it  runs  on  VAXs,  and  it  runs  in  places  like  Track, 
Wizmer  and  White  Vans. 


I  put  this  next  figure  in  because  I  wanted  to  remind  myself  to  talk  about  assets.  A 
very  important  concept  in  AURA  is  to  separate  your  definitions  between  assets  and  jobs. 

I  have  referred  to  assets  as  physical  things,  such  as  people  and  equipment  that  are  in  a 
unit  Assets,  for  example,  are  the  kinds  of  things  you  see  in  the  figure.  They  are 
deployed.  Assets  are  the  things  that  you  can  count.  On  the  other  hand,  each  of  the 
assets  has  some  sort  of  capability  that  the  commander  can  apply  to  doing  a  job. 
Somebody  operates  the  radio.  It  need  not  be  the  guy  whose  MOS  is  radio  operator,  but 
if  I  am  a  commander  and  I  have  to  assign  somebody  else  in  that  slot.  I  am  going  to  take 
a  degradation.  There  is  a  human  factor.  The  human  factor  is  the  bridge  Utween  the 
assets  which  are  the  things  that  you  have  and  the  jobs  that  they  can  do.  You  apply  the 
human  factors  to  the  assets  and  you  come  up  with  how  much  good  can  they  do  for  your 
unit  I’ll  try  to  really  make  this  concept  clear  because  it’s  really  one  of  the  things  that 
has  made  AURA  easy  to  apply  human  factors  to. 

It’s  also  important  that  I  describe  how  AURA  evaluates  jobs,  how  AURA  evaluates 
the  mission,  and  the  steps  in  describing  a  unit  function.  First  one  has  to  quantify  the 
mission.  You  notice  in  the  beginning  when  I  talked  about  measures  of  effectiveness,  I 
came  up  with  a  very  quantitative  measure  of  effectiveness.  It  is  number  of  rounds  that 
are  loaded  per  hour  or  fired  per  hour,  number  of  trucks  that  are  loaded,  or  something 
tk  .t  I  can  count.  It's  important  to  quantify  the  mission,  because  after  quantifying  the 
mission.  I  am  going  to  go  through  and  describe  exactly  what  kinds  of  jobs,  what  kind  of 
functions  have  to  be  accomplished,  in  order  to  get  that  mission  done  at  the  level  that  I 
quantified  it. 

Here  is  an  example  of  a  simple  flow  diagram.  This  is  a  unit  that  has  to  load  trucks. 
In  particular  this  unit  receives  instructions  from  someplace  telling  it  what  to  put  on  the 
trucks.  It  receives  the  instructions  either  by  radio  or  telephone,  the  way  my  unit  is  set 
up.  On  the  average.  75%  of  the  items  that  I  am  going  to  load  on  the  trucks  can  be 
loaded  by  a  forklift  and  a  forklift  operator,  they  are  fairly  light  items,  or  if  push  came 
to  shove,  I  could  hand  load  them,  but  that’s  not  quite  the  way  to  do  it.  The  other  25% 
of  the  items  to  be  loaded  are  heavy  items,  I  have  to  use  a  crane,  operator  and  rigger.  I 
have  to  have  trucks  and  drivers.  It's  nice  to  have  a  loadmaster  to  kind  of  get  these  guys 
along,  although  we  can  also  describe  this  as  a  nice-to-have  job;  that  is,  there  is  some 
intrinsic  managerial  capability  in  the  outfit,  the  outfit  will  still  load  trucks  if  the 
loadmaster  isn’t  there,  but  he  is  nice  to  have.  This  is  what  I  meant  by  a  flow  diagram. 
This  is  the  way  that  AURA  thinks  about  doing  a  job.  Each  of  these  jobs  has  to  be  done. 
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The  guys  that  come  in  here  and  hand  load  can  have  any  MOS.  They  just  need  to  be  able 
to  get  the  job  done. 

This  is  the  way  AURA’s  commander  thinks  about  doing  his  job  too.  AURA’s 
commander  also  has  the  following  thought.  "Suppose  that  my  job  were  to  load  ten 
trucks  per  hour,  and  1  only  have  seven  trucks  per  hour  available,  and  my  semi-deaf 
radio  telephone  operator  can  Only  take  five  messj"fe»  per  hour?"  I  7/ill  loa^  five  trucks 
per  hour.  The  ability  of  this  unit  is  dictated  by  the  choke  point  in  the  flow  diagram. 
Commanders  all  engage  in  choke  point  analysis.  When  commanders  go  about  assigning 
their  assets  after  being  attacked,  they  start  assigning  assets  preferentially  to  the  choke 
points.  That’s  the  way  they  are  trained  to  do  their  job  assignments.  Commanders  and 
AURA  have  gotten  a  little  smarter  over  the  years.  They  know  enough  to  save  their 
most  versatile  people.  They  know  enough  to  worry  about  the  hard-to-fill  jobs.  But  in 
the  final  analysis  the  commander  is  going  to  take  his  assets,  apply  them  to  the  jobs,  and 
at  some  point  he  is  goiT  g  to  get  stuck.  At  that  point,  we  have  determined  the 
effectiveness  of  the  unit.  The  effectiveness  will  be  dictated  by  the  choke  point;  the 
ability  of  the  unit  to  do  its  job.  Notice  (incidentally)  in  the  process  of  describing  this 
flow,  I  have  alluded  to  quite  a  few  different  mathematical  relationships  between  the 
things. 

The  next  figure  presents  some  of  the  various  relationships  that  are  found  in  AURA. 

There  are.  besides  the  "and."  and  the  "or's,"  the  other  relationships  available  in 
AURA.  It’s  the  ability  to  link  and  combine  these  various  things  that  have  allowed  AURA 
to  be  a  fairly  flexible  kind  of  system.  Pretty  much  things  are  going  to  be  "and’s," 
"and/or’s"  or  "sums  of  things,"  or  combinations  of  "and,"  "and/or’s"  and  "sums  of  things." 

I  just  point  out  we  have  done  a  number  of  systems  that  have  been  really  quite 
complex,  including  an  aviation  maintenance  company  that  had  something  like  240  or  250 
different  jobs.  Interesting  kind  of  company,  because  there  are  so  many  specialists  in  it. 
There  is  a  lot  of  covering  up  within  some  specialties,  but  certain  weak  links  that  really 
would  come  out  in  a  group  like  that.  In  describing  AURA.  I  have  talked  about  the  unit 
AURA  as  a  whole  and  what  it's  doing.  It's  moving  through  a  day  and  taking  its  lumps 
and  then  trying  to  reallocate  its  assets.  The  commander  is  going  to  worry  about  the 
hardest  filled  jobs  and  all  that  sort  of  thing. 
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The  thing  I  haven’t  shown  about  AURA  is  the  relationship  between  the  assets  and 
the  jobs.  That  relationship  in  its  most  general  form  is  described  by  what  I  call  here  a 
link  effectiveness  curve.  Basically,  it  says  that  with  no  assets  at  all  I  might  have  some 
capability.  Beyond  some  threshold  there  should  be  an  increased  ability  to  do  a  job  as  I 
put  assets  in  up  to  some  optimum  and  beyond  that  it  doesn’t  help  to  put  any  more  in. 
This  is  the  most  general  form  of  link  effectiveness  curve.  Most  jobs  (if  you  don’t  know 
much  else  about  them)  get  models  like  this. 

There  are  jobs,  however,  like  the  loadmaster,  where  the  system  continues  to 
function,  even  with  the  elimination  of  the  position.  Without  a  loadmaster  there  is  still 
some  intrinsic  system  capability.  Handloaders  (on  the  other  hand)  have  a  threshold. 
You  need  a  couple  of  them  or  you  can’t  lift  a  pallet;  therefore  there  is  a  threshold. 

It’s  important  to  note  that  what  we  are  talking  about  is  the  abscissa  of  the  Link 
Effectiveness  Curve,  the  effective  allocation  of  assets.  Here  is  where  the  human  factors 
come  in.  Because  if  I  have  a  man  who  is  at  half  capability  because  he  has  taken  a  whiff 
of  nerve  gas,  or  because  he  is  wearing  MOPP  gear,  (what  I  mean  by  half  capability  is 
that  when  I  put  him  in  a  job.  he  will  do  half  as  well)  he  would  be  half  as  much  of  a 
contributor  to  th*  job  as  he  would  if  he  were  a  whole  man.  So  this  is  clearly  the 
obvious  place  to  put  in  human  factors.  Human  factors  do  not  affect  the  unit.  Human 
factors  affect  the  ability  of  the  asset  to  do  the  job.  Then  it’s  up  to  the  commander  to 
use  those  assets  as  well  as  he  can  to  try  to  optimize  the  ability  of  the  unit  to  work.  So 
my  human  factors  are  going  to  come  in  on  the  abscissa  of  the  Effectiveness  Curve.  They 
are  going  to  degrade  the  assets  the  commander  has  when  he  goes  to  assign  them  to  doing 
jobs. 


To  summarize  AURA,  there  are  assets  that  have  physical  characteristics  so  they  can 
be  deployed,  and  they  are  vulnerable  to  weapon  effects  that  can  be  used  against  them. 
These  assets  can  be  degraded  because  of  what  happens  to  them.  The  degraded  assets  or 
effective  assets  can  be  applied  to  a  job.  Depending  on  how  well  this  job  and  all  the 
other  jobs  can  be  done,  and  how  well  my  smart  commander  allocates  his  assets 
determines  the  success  of  the  mission. 

The  next  diagram  describes  the  AURA  functional  structure. 
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There  are  three  parts,  and  each  has  its  own  algorithm.  The  algorithms  use  inputs 
that  come  from  the  weapon  effects,  and  the  outputs  indicate  how  well  the  individuals 
can  do  their  jobs.  The  smart  commander  optimizes  that  to  make  the  unit  work. 

The  AURA  outputs  as  shown  in  the  next  figure  indicate  how  well  the  units  can  do 
their  job.  They  provide  information  on  personnel  losses,  task  performance,  etc.  That’s 
AURA  in  a  nutshell. 

Let  me  continue  by  briefly  giving  you  a  few  of  the  human  factors  models  that  are 
currently  running  in  AURA;  effectiveness  of  substitutes,  sublethal  doses,  etc..  There  is 
always  a  trade-off  between  accuracy  and  rate.  I  think  almost  on  any  job  you  can  find, 
you  can  speed  up  if  you  are  willing  to  give  up  accuracy  up  to  a  limit,  and  up  to  a  limit 
you  can  slow  down  and  do  a  little  better  job. 

It  is  assumed  in  the  way  we  train  troops,  in  the  way  everything  is  done,  that  there 
is  a  minimum  standard  of  performance  (shown  by  the  dashed  line  in  the  next  figure), 
and  that  the  troops  will  perform  to  that  level.  They  will  perform  to  that  level,  even  if 
it  takes  them  more  time.  The  man  on  the  normal  curve  (the  ”N”  in  the  figure  indicates 
the  normal  curve),  is  undergraded,  and  he  can  trade  off  accuracy  for  rate,  as  long  as  he 
operates  someplace  above  the  dashed  line.  He  is  going  to  operate  above  the  dashed  line, 
because  he  has  to  have  that  level  of  accuracy  to  pass  his  job.  The  accuracy  level  dictates 
the  rate  at  which  the  normal  troop  is  going  to  operate.  Of  course,  there  are  standard 
deviations,  but  we  can  define  an  accuracy  and  a  rate  at  which  that  guy  is  going  to 
operate.  When  he  is  degraded  he  still  has  the  trade-off  possibility.  We  again  assume 
(and  based  on  everything  that  we  have  seen  so  far  it’s  a  good  assumption),  that  he  will 
still  try  to  do  his  job  correctly.  He  is  not  going  to  put  the  round  in  backwards,  he  is  not 
going  to  call  somebody  else  instead  of  the  call  he  is  supposed  to  make;  he  is  going  to  keep 
trying  until  he  does  his  job  correctly,  and  therefore,  he  is  going  to  attempt  to  operate  on 
or  above  the  dashed  line.  The  degradation  therefore  comes  in  a  altered  rate  of 
performance. 

It's  important  to  have  a  grasp  of  this  concept  when  one  is  defining  the  mission 
blocks  that  we  have.  If  I  say  an  individual  can  load  2200  short  tons  per  day,  and  the  guy 
rcw  has  radiation  sickness,  he  is  not  going  to  put  the  wrong  thing  on  the  trucks,  he  is 
going  to  slow  down.  I  don’t  have  to  worry  about  quantifying  the  effect  of  putting  the 
wrong  thing  on  the  truck,  but  what  I  do  have  to  quantify  is  what  happens  when  he  is 
sick  and  he  is  not  loading  as  a  rapidly  as  he  did. 
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This  notice  is  based  on  medical  evidence  from  the  toxicology  groups,  from  the 
oncology  wards  and  other  sources.  It  appears  that  cognitive  tasks  are  not  degraded,  but 
primarily  with  the  degradations  that  we  see  it’s  certainly  true  in  MOPP  gear.  From  all 
of  our  tests  in  the  field  the  degradations  we  see  are  in  rate  of  performance. 

The  first  human  factors  model  we  want  to  discuss  is  just  a  real  simple  one. 
Effectiveness  of  substitutes  is  the  simplest  algorithm  we  have.  When  the  user  specifies  a 
truck  driver,  he  says  the  guy  who  normally  does  this  job  is  the  guy  whose  MOS  is  such 
and  such.  He  does  it  at  100%.  It  can  also  be  done  by  a  number  of  other  people  at  100%. 
There  are  individuals,  however,  that  are  only  going  to  perform  80%  of  normal,  and  good 
commanders  know  who  they  are.  That's  the  simplest  of  our  algorithms. 

Somewhat  more  complicated  is  the  effect  of  a  nuclear  dose.  In  the  old  models 
individuals  exposed  to  nuclear  radiation  either  lived  or  died.  Suppose,  however,  you  are 
using  3,000  rads  for  the  kill  criteria,  and  an  individual  received  2.999  rads.  In  the  old 
model,  he  is  fine.  That  was  the  model  we  were  using  until  IDP.  IDP  was  an  extremely 
important  project.  What  we  do  now  is  quantify  the  individual’s  performance.  That 
fellow  at  3,000  rads  for  the  first  couple  minutes  is  still  functional,  and  then  he’ll  start 
degrading.  But  as  a  matter  of  fact,  so  will  the  person  at  500  rads.  He  is  going  to  last  a 
little  longer,  and  he  is  going  to  have  a  couple  of  hours  of  good  work,  but  he  is  going  to 
go  into  that  prodromal  phase  too.  So  we  no  longer  have  this  go.  no-go  break.  AURA 
keeps  track  of  the  doses  that  everyone  has  and  the  time  which  they  received  it,  and  when 
a  commander  goes  to  assign  a  dosed  individual  to  a  job.  then  the  code  checks  the  guy’s 
dose  and  his  time  pops  into  the  curve  shown  in  the  next  figure  and  determines  what  kind 
of  degradation  he  should  have  at  that  time. 

On  top  of  this  model  (not  shown  here)  is  an  incidence  matrix.  We  have  recently 
expanded  the  work  of  the  IDP,  because  at  low  doses  the  effects  are  very  dependent  on 
individual  differences.  For  these  doses  we  now  do  a  Monte  Carlo  draw  against  an 
incidence  probability  to  determine  whether  an  individual  is  going  to  be  one  of  those  who 
are  sick  are  not. 

So  we  use  one  level  of  sophistication  beyond  what  is  shown  in  the  figure.  It’s 
certainly  not  a  go,  no-go  situation  any  more. 
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Simulation  of  chemical  warfare  is  similar,  but  somewhat  more  complicated  than 
nuclear  warfare.  It  is  really  tough  to  keep  track  of  those  chemical  clouds  and  where 
they  go.  It  is  also  difficult  to  know  what  job  each  individual  is  doing,  how  hard  they  are 
breathing,  and  how  long  they  are  exposed  to  the  cloud.  A  dose  of  chemical  exposure 
becomes  much  like  giving  someone  a  dose  of  radiation,  that  is,  there  is  a  time 
dependence.  So  as  a  function  of  time  the  nerve  agent  victim  also  is  going  to  have  some 
degradation  in  effect,  and  then  he  is  going  to  recover  or  he  is  not  going  to  recover.  He 
is  going  to  get  to  some  point  where  the  medics  say  "hey,  this  guy  is  gone,"  and  they  give 
him  a  double  shot  of  tupamechloride  and  haul  him  away  and  therefore  he  suddenly 
disappears  from  the  group.  Given  that  he  is  not  yanked  out  of  the  scenario,  his  ability 
to  perform  a  job  if  he  has  gotten,  say,  a  tenth  of  a  lethal  dose,  is  going  to  be  degraded. 
He  is  still  there  and  he  is  still  an  asset.  When  push  comes  to  shove,  a  commander  might 
have  to  put  him  on  a  radio,  or  whatever,  but  his  ability  is  going  to  be  degraded. 

An  additional  complexity  to  chemical  warfare  is  the  fact  that  even  more  than 
nuclear  there  is  a  tremendous  variation  in  individuals,  in  individual  susceptibility  to 
chemical  agents.  The  distribution  of  reactions  to  chemical  agents  is  described  by 
something  that  is  called  the  "bliss  slope."  which  is  the  inverse  of  a  log  probate  slope. 
When  a  non-log  scale  is  used,  it  looks  like  the  cumulative  log  normal  type  of 
distribution.  The  distribution  gives  the  percentage  of  the  population  at  a  given  dose  that 
would  show  certain  symptoms.  We  have  built  this  chemical  model  into  AURA  so  that 
when  the  commander  is  trying  to  determine  how  well  he  can  get  his  job  done,  the  model 
looks  at  each  one  of  his  assignments  and  determines  the  chemical  dose  each  individual 
has  received.  The  model  also  checks  to  see  where  the  individual  falls  in  the  population. 
Le..  is  he  one  of  the  strong  ones  or  one  of  the  weak  ones,  and  based  upon  that,  how  much 
he  is  degraded? 

Clearly  these  are  not  models  that  we  developed  at  BRL.  They  came  out  of  the 
Chemical  community.  Primarily  we  got  them  through  CROC  (Chemical  Research  and 
Development  Command)  but  it’s  another  algorithm  that  we  have  integrated  into  AURA. 
Biological  warfare  is  something  that  people  do  think  about,  but  for  which  we  do  not 
have  a  model.  Biological  effects  will  probably  follow  the  same  type  of  algorithm  as 
chemical  and  nuclear,  so  we  are  not  worried  about  whether  we  can  make  the 
connections  or  not.  The  biggest  question  regarding  biological  warfare  concerns 
dissemination.  Certainly  don’t  count  the  number  of  spores.  If  anybody  has  any  good 
algo,  ithms,  we  are  certainly  interested  in  seeing  them. 
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A  related  topic  we  are  interested  in  is  the  effects  of  Mission  Oriented  Protective 
Posture  (MOPP),  chemical  protection  gear,  on  unit  performance.  What  happens  when 
you  put  on  chemical  gear?  Well,  you  have  a  couple  of  effects  that  come  out  of 
chemical  gear  and  both  limit  human  performance.  In  a  large  number  of  the  chemical 
studies  we  have  done  (including  one  for  the  Navy),  the  effects  of  putting  people  in  the 
MOPP  gear  were  really  the  dominant  effects  in  the  analysis.  People  in  this  gear  really 
can’t  operate  very  well.  The  gear  bothers  them;  there  is  an  encumbrance,  it  increases 
the  fatigue,  and  there  is  the  possibility  of  heat  stress.  These  are  not  unrelated  factors. 

Heat  stress  is  a  casualty  producer,  but  I  wanted  to  bring  it  here  because  there  is  this 
trade-off.  In  MOPP  gear  you  can  push  people  a  little  harder.  You  can  increase  the 
work  rest-rest  ratio,  with  more  work  and  less  rest,  but  the  cost  of  that  is  an  increase  in 
body  core  temp.  Metabolic  work  rate  goes  up,  and  there  is  an  increased  possibility  of  a 
casualty.  This  is  a  real  effect  commanders  have  to  face  out  in  the  field.  For  the 
metabolic  work  rate,  there  are  algorithms  available.  This  particular  algorithm  is  the  one 
that  we  call  T-Core.  It  is  a  pregram  that  we  wrote  but  it’s  based  on  work  that  came  out 
of  ARIEM.  (JSARIEM  is  the  Ui>.  Army  Research  Institute  for  Environmental  Medicine 
at  Natick.  A  researcher  by  the  name  of  Goldman  did  most  of  the  work  on  heat  stress 
and  body  core  temperature  build-up.  The  body  core  temperature  is  that  function  of 
starting  core  temperature  plus  heat  capacity,  and  the  sum  of  the  energy  flows.  The 
energy  flow  reflects  a  number  of  different  sources,  but  the  most  important  is  the 
metabolic  work  rate.  The  metabolic  work  rate  depends  on  a  resting  rate  that  you  can’t 
get  below,  plus  the  amount  of  physical  work  an  individual  is  doing.  Based  on  this  model 
we  can  play  the  trade-offs  between  degrading  a  person  with  MOPP  gear  by  slowing  him 
down  and  keep  his  core  temperature  under  control,  or  let  him  work  a  little  harder,  and 
take  a  chance  on  heat  stress.  These  are  all  human  performance  parameters  and 
important  ones  to  trade  off  against  operational  requirements. 

The  final  effect  I  want  to  discuss  in  terms  of  MOPP  gear  and  chemical  warfare  is 
the  idea  of  fatigue.  Even  if  a  person  is  not  wearing  MOPP  gear,  the  normal  working 
individual  after  a  time  is  going  to  show  a  performance  dec.ement.  The  time  it  takes 
will  depend  on  the  job  and  the  individual.  It  may  take  12  hours  or  maybe  24  hours,  but 
it  will  happen. 
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What  happens  when  he  puts  on  MOPP  gear?  Well,  first  of  all  he  is  encumbered. 
We  have  made  large  numbers  of  measurements  to  quantify  the  effects  of  this 
encumbrance.  We  have  taken  field  measures  of  maintenance  groups,  and  we  have  had 
marines  running  around  on  night  recon  patrols;  plus  we  gathered  a  lot  of  information 
from  the  Air  Force  on  maintenance  tasks  that  they  have  done  in  and  out  of  MOPP  gear. 
These  studies  have  given  us  a  rather  nice  data  base  on  how  much  an  individual  is 
encumbered  by  MOPP  gear.  As  a  matter  of  fact,  we  have  set  the  NATO  standards. 
There  is  a  standard  NATO  technique  now  that  is  centered  on  the  data  base  at  BRL.  for 
how  much  an  individual  is  encumbered. 

Another  effect  of  wearing  MOPP  gear  is  that  the  individual  is  going  to  tire  more 
quickly.  He  tires  more  quickly  even  if  he  isn't  working,  because  his  metabolic  rate  goes 
up.  His  heart  beat  is  faster  and  his  respiration  rate  goes  up,  because  that's  the  only  way 
you  can  maintain  the  body  core  temperature  and  get  rid  of  excess  heat  buildup.  If  he  is 
going  to  tire  more  quickly,  that  means  that  his  performance  will  drop  a  little  more 
precipitously.  We  don’t  have  a  great  deal  of  information  on  this  yet.  but  it  is  an  area 
we  will  be  working  on.  MOPP  gear  will  be  another  module  in  AURA.  When  a  unit 
commander  goes  to  assign  somebody  to  a  task,  the  model  will  check  to  see  whether  he  is 
in  MOPP  gear  or  not.  and  how  long  he  has  been  in  MOPP  gear.  Based  on  these  factors, 
along  with  information  on  the  last  time  he  rested,  he  places  him  on  a  curve.  The  curve 
that  we  use  now  is  linearized,  and  one  of  the  contacts  I  have  already  made  at  this 
meeting.  Dr.  Naitoh.  suggests  that  we  can  do  octter  than  the  linear  model. 

In  the  model  now  we  store  up  what  I  call  sleep  units,  "slunits,"  which  an  individual 
then  uses  at  some  rate  that  depends  on  the  job.  How  fast  he  uses  these  units  up  depends 
on  the  job,  and  how  many  he  needs  for  100%  effectiveness  is  also  job  dependent.  When 
the  user  describes  the  various  jobs,  he  has  a  couple  of  parameters  that  describe  the 
demand,  and  the  tiring  rate  of  the  job.  The  individual  works  until  he  drops  below  a 
certain  number  of  my  "slunits,”  at  which  point  his  capabilities  start  to  decrease.  One  of 
the  things  that  AURA  does  being  a  very  smart  commander,  is  it  makes  the  decision 
whether  he  wants  the  individual  to  sleep  or  not.  Can  I  do  without  this  asset?  If  I  do 
without  this  asset  what  does  it  cost  me,  and  what  am  I  going  to  gain  if  I  put  him  to 
sleep? 
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The  last  issue  1  want  to  just  touch  on  is  psychological.  We  do  not  yet  incorporate 
psychological  effects  in  the  model.  We  are  in  the  process  of  installing  the  first  stage  of 
psychological  effects.  The  psychological  effects  that  we  are  installing  will  be 
catastrophic  ones,  tsat  is,  the  increase  in  casualties  due  to  the  production  of 
neuropsychiatric  (NP)  casualties  is  based  on  a  magnificent  piece  of  work  by  Dr.  Levin. 
This  is  also  work  that  came  out  of  the  intermediate  nuclear  dose  program  funded  by  Dr. 
Young.  The  psychological  information  that  is  available  deals  with  very  severe  cases,  and 
will  be  used  in  the  model  as  a  casualty  multiplier. 

That  pretty  much  summarizes  what  I  wanted  to  talk  about.  I  have  given  you  a 
flavor  for  the  algorithms  that  are  in  the  model,  how  they  hook  into  a  code,  and  what 
kind  of  effect  they  make.  Based  upon  the  comparisons  we  have  made  the  results  appear 
to  be  quite  realistic. 

I  would  like  to  leave  you  with  one  final  point.  Anyone  that  suggests  that  he  is 
leaving  a  variable  out  of  his  model  because  it  can't  be  simulated,  is  telling  an  untruth. 
The  absence  of  a  model  is  a  model.  If  you  run  a  study,  and  you  come  out  with  an 
answer,  you  have  played  absolutely  everything.  It's  just  that  some  things  you  haven't 
played  terribly  well.  You  have  played  some  of  the  factors  by  multiplying  by  one.  The 
offshoot  of  this  is  that  a  model  that  gets  some  of  the  characteristics  certainly  has  to  be 
better  than  pretending  you  are  not  playing  it  at  ail,  because  you  are  playing  it.  If  we 
get  people  to  just  not  last  forever,  that  has  to  be  an  improvement.  If  we  show  that  not 
everybody  is  100%  gung  ho  in  the  face  of  fire,  we  have  done  something,  and  we  probably 
made  an  improvement. 

The  absence  of  a  model  is  a  model. 
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ADDRESS  BY  DR.  THOMAS  J.  YENCHA 


My  name  is  Tom  Yencha.  I  am  the  principal  investigator  and  program  manager 
for  the  Naval  Capability  Assessment  of  Forces  of  Threat.  Before  Paul  Kirk  tells  you 
about  NUKA.  I  wanted  to  give  you  some  background  on  the  project. 

We  developed  our  system  of  models  as  a  tool  to  perform  a  job.  Our  project  was 
not  a  project  to  develop  a  model,  we  had  to  do  that  because  there  was  nothing  else 
available  that  would  do  what  we  wanted  to  do.  What  we  wanted  to  do  was  to  predict 
CB  defensive  technological  shortfalls  in  the  present  fleet,  and  then  list  6.2  R&D 
initiatives  that  can  be  started  to  relieve  these  deficiencies.  We  started  this  project  in 
1982  -  1983.  and  at  that  time  there  were  no  models  available  to  predict  the  fleet  CB 
shortfalls,  or  to  develop  initiatives  to  alleviate  the  shortfalls.  Therefore,  we  had  to 
come  up  with  our  model. 

The  next  figure  is  a  kind  of  a  line  drawing  to  shew  you  our  methodology.  This 
model  is  in  some  ways  new  work,  and  in  some  ways  modifications  of  old  work.  The 
acronym  DAWN  stands  for  a  rather  long  name:  Deposition  and  Weathering  of  Chemical 
Agents  about  a  Naval  Vessel.  That  model  has  been  developed  in  the  past  four  years,  and 
it’s  predicated  on  the  News  Eye;  the  Army  News  Eye  (NUSEY)  methodologies.  But  as 
some  of  you  modeleis  might  know,  the  NUSEY  methodology  is  a  table  top  model  which 
lays  down  liquid  deposition  and  vapor  movement  on  a  flat  plane,  and  it  has  been 
evolving  to  take  into  account  three  dimensional  barriers.  In  1983  it  didn't  have  any  of 
that  capability,  and  even  now  it  doesn’t  have  the  capability  to  put  a  small  barrier  and 
give  you  accurate  dosages  and/or  concentrations  around  that  barrier.  We  feel  our 
model  does.  What  our  model  needs  to  operate,  is  information  that  describes  our 
operational  situation;  things  like  direction  of  movement  of  a  ship,  people  needed  to 
operate  the  ship  and  so  forth,  and  we  also  have  a  digitized  ship  data  base  that  gives  a 
picture  of  what  the  ship  would  look  like. 

We  input  tnis  information  into  the  DAWN  model  along  with  the  operational 
situation,  and  the  types  of  weapons  and  locations  o?  those  weapons  that  are  attacking  the 
ship.  The  DAWN  model  tracks  the  deposition  of  liquid  on  the  ship  from  the  release  of 
the  agent  through  its  evaporation  and  dissipation.  The  model  tracks  the  distribution  of 
the  agent  concentration  as  a  function  of  time,  and  feeds  that  data  into  another  model. 
At  the  time  I  did  this  flow  chart,  it  was  called  the  SHPPF.N  model,  but  since  then  we 
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have  modified  lhat  model  and  call  it  the  ventilation  model.  The  model  covers  the 
mechanical  transfer  of  the  agen;  through  the  outside  of  the  ventilation  system  into  each 
of  the  compartments  inside  the  ship.  The  output  of  that  model  is  a  time  history  of 
concentration  and/or  a  time  history  of  dose  in  each  of  the  compartments  of  the  ship.  In 
order  to  operate  the  SHPPEN  model,  we  need  our  Operational  Thread  Environment, 
and  we  need  rather  an  extensive  data  base  for  the  HVAC  (heating,  ventilation  and  air 
conditioning)  data.  HVAC  data  is  a  description  of  the  ventilation  of  the  ship. 

We  track  an  agent  from  its  point  of  release  to  the  vicinity  of  the  ship  using  the 
NUSEY  model  or  a  variation  of  the  NUSEY  model.  Once  the  agent  gets  approximately 
80  to  100  feet  away  from  ihe  ship,  there  are  three  dimensional  effects  of  the  ship  itself 
that  perturb  the  wind  field  around  the  ship  and  you  no  longer  can  really  satisfactorily 
use  the  NUSEY  model.  At  the  present  time  we  are  using  a  potential  flow  model  to 
model  the  agent  vapor  transfer  around  the  ship.  We  still  use  the  NUSEY  methodologies 
to  transfer  the  liquid  down  to  the  ship  surface  itself.  We  also  use  a  couple  other 
models.  If  you  are  getting  the  idea  that  our  model  is  a  group  of  submodules,  you’re 
correct.  It’s  structured  in  some  ways  similar  to  the  AURA  model. 

One  of  the  models  we  use  is  an  Army  vehicle  deposition  model  that  was  developed 
by  a  contractor  for  the  Army.  It  was  basically  developed  to  describe  the  impact  of  a 
liquid  agent  on  a  moving  tank,  and  then  track  the  evaporation  of  that  agent  off  the 
tank.  We  have  modified  that  model  to  describe  the  ship  environment. 

Obviously  the  resolution  in  our  models  is  significantly  higher  than  the  resolution 
you  have  been  talking  about  in  your  ground  force  simulation  models.  Most  of  the  other 
models  that  have  been  talked  about  use  a  resolution  of  a  couple  hundred  meters.  We 
are  talking  about  pieces  of  a  ship  that  are  on  the  order  of  meters  in  resolution. 

The  next  thing  1  would  like  to  talk  about  is  the  graphical  output  from  this  model. 
We  use  extensive  graphics,  and  the  next  three  figures  show  the  type  of  output  we  obtain 
from  our  model.  W<*  are  using  basically  a  MicroSAINT  computer  to  run  the  simulation 
itself.  For  graphic  output  we  had  prsviously  used  the  Tektronics  4125  terminal,  but  we 
have  since  switched  c*er  to  Emulations  of  that  terminal  on  an  IBM  PC  386  type  of 
computer.  Using  the  IBM  is  significantly  cheaper.  The  Emulation  only  cost  us  $900.  and 
the  computer  itself  was  significantly  cheaper  than  a  4125.  Plus  the  4125  (hat  we  had,  we 
paid  just  under  $30,000  for  that  terminal,  and  it  did  not  allow  us  to  capture  any  of  the 
data  that  went  to  the  screen.  We  could  put  it  on  the  screen  and  then  we  could  print  it, 
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but  that  was  it.  and  it  takes  a  rather  large  amount  of  time  to  put  graphics  on  the  screen. 
Our  ship  model  graphics  take  approximately  five  minutes.  The  model  puts  out  a  graphic 
image  every  one  second  of  the  attack,  if  we  are  going  to  spend  four  or  five  minutes  on 
each  graph,  it  will  take  a  large  amount  of  time  for  a  single  attack.  Also,  it  would  not 
allow  us  to  demonstrate  the  model  effectively  to  anybody  else.  With  this  PC  386 
Emulation  it  takes  us  about  half  the  time  to  put  an  image  on  the  screen.  But  the  system 
allows  us  to  save  images  to  a  disk,  and  recall  them  back  in  two  and  a  half  seconds,  so  in 
terms  of  demonstrating  it  to  our  sponsors  and  other  people,  it  is  more  effective. 

The  first  figure  shows  the  attack  of  a  real  intelligent  weapon.  It  burst  right  in 
front  of  the  front  bulkhead  on  an  FFG  class  ship.  Six  seconds  later  the  cloud  has  moved 
aft.  On  the  computer  screen  we  have  colored  the  different  sections  of  the  ship  to 
indicate  different  liquid  depositions  in  grams  per  square  meter.  We  also  see  how  all  the 
liquid  clouds  are  splitting  up.  We  have  started  out  with  that  single  cloud,  and  as  time 
progresses  the  single  cloud  will  separate  into  multiple  clouds,  depending  on  the  mass  and 
radii  of  the  liquid  droplets  in  the  cloud.  At  the  time  of  14  seconds  the  clouds  have 
progressed  further  down  the  ship.  This  ship  is  moving  at  20  knots.  In  the  space  of 
approximately  25  seconds  this  ship  is  no  longer  interacting  with  the  clouds  of  the  weapon 
release.  The  ship  is  still  interacting  with  the  evaporation  of  the  liquid  off  the  surfaces, 
but  basically  the  attack  is  over  and  the  weapon  can  no  longer  effect  that  ship.  The  time 
that  we  have  to  react  to  the  attack  is  much  leas  than  you  have  with  models  like  the 
scenarios  that  you  would  have  in  the  Army  or  Marine  Corps. 

Basically,  that’s  all  I  wanted  to  tell  you  about  the  NURA  precursor  models.  The 
NURA  model  we  use  is  different  than  the  AURA  model  in  that  instead  of  representing  a 
two  dimensional  Army  battlefield,  we  have  strung  the  compartments  in  the  ship  into  a 
one  dimensional  array,  representing  the  functional  description  of  the  ship.  We  have 
been  putting  out  a  lot  of  reports  on  various  weapon  types  and  ship  types  using  the 
model.  I  have  five  technical  reports  being  published  right  now. 
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My  name  is  Paul  Kirk,  and  as  Dr.  Kolpcic  mentioned,  we  use  a  version  of  the 
AURA  model  that  we  call  NURA  (Naval  Unit  Resiliency  Analysis).  We  have  applied  the 
NURA  model  to  the  very  specific  area  of  Navy  chemical  defense.  To  do  this,  the  two 
models  that  Tom  mentioned,  DAWN  and  VENM  (Ventilation  Model)  were  developed. 
Their  output  provided  the  input  for  the  chemical  warfare  side  of  NURA.  We  do  not  use 
the  nuclear  and  conventional  warfare  capabilities  of  AURA,  but  we  have  plans  to 
combine  that  with  the  chemical  warfare  side  in  the  future. 

To  adapt  the  AURA  model  to  naval  scenarios  we  made  the  changes  mentioned,  and 
have  developed  a  utility  program  to  map  the  two  dimensional  grid  of  AURA  onto  a  one 
dimensional  system.  We  take  the  chemical  contamination,  location,  and  time  history, 
and  map  them  onto  a  one  dimensional  grid.  We  also  map  the  personnel  deployment  on 
the  shipboard  onto  the  same  one  dimensional  grid  so  that  they  can  be  compared  directly 
with  the  dosages  that  the  personnel  receive,  and  we  can  evaluate  the  results.  All  this  is 
done  without  changing  the  functional  structure  of  the  AURA  model. 

Human  response  to  CW  attack  is  the  only  indicator  of  forces  resiliency.  We  use 
the  one  factor  that  Dr.  Kolpcic  mentioned,  the  effect  of  these  weapons  against 
equipment.  The  only  thing  we  use  to  measure  the  impact  of  an  attack  is  human 
response.  There  are  several  human  response  data  requirements  for  chemical  warfare 
modeling.  The  MOPP  degradation,  and  the  toxic  agent  effects.  Currently  there  have 
been  a  number  of  studies  done  to  come  up  with  MOPP  degradation  values,  and  I 
haven’t  seen  great  agreement  amongst  the  studies  that  I  have  seen.  The  Navy  currently 
has  a  doctrine  of  using  strictly  a  protective  mask  lor  personnel  located  interior  to  the 
ship  during  vapor  agent  attacks.  This  is  a  Navy  doctrine,  and  as  far  as  we  have  been 
able  to  determine,  nobody  has  actually  studied  this  problem  to  see  low  degradation 
values  adjust. 

The  toxic  agent  effects  are  divided  into  three  areas.  First,  the  subletha!  effects  are 
symptoms  that  cause  performance  degradation  without  actually  killing  the  person.  The 
amount  of  agent  needed  to  do  this  can  be  considerably  less  than  a  lethal  dose.  The 
second  point  concerns  the  onset  time  of  effects,  which  is  the  length  of  time  after 
exposure  to  an  agent  before  the  poor  performance  degradation  becomes  apparent. 
Agents  currently  available  range  from  a  few  minutes  to  several  hours  for  onset  times. 
And.  the  third  point  is  lethality.  Toxicity  values  are  given  in  lethal  dosages  for  50%  of 
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the  population  so  that  chemical  casualties  can  be  calculated  on  a  statistical  bases.  The 
NURA  model  combines  all  three  of  these  factors  and  comes  up  with  an  aggregate 
effectiveness  value. 

As  an  example  of  the  type  of  study  we  do,  the  next  graph  shows  the  effect  of 
varying  amounts  of  agent  against  a  single  unit,  a  damage  control  unit  on  a  ship.  As  you 
can  see.  increasing  the  amount  of  agent  above  20  kilograms  has  no  greater  impact  on  the 
unit’s  effectiveness.  This  is  the  type  of  study  we  do  to  evaluate  alternatives;  see  what 
amount  of  agent  would  be  realistic  to  expect. 

Each  ship  is  divided  up  into  several  functional  units.  The  units  are  listed  here  on 
the  right,  and  we  studied  them  individually  and  as  a  whole.  These  units  are  functional 
and  have  no  relationship  to  Navy  administrative  organization.  They  are  strictly 
organized  this  way  because  they  are  combined  together  to  do  one  mission. 

As  you  can  see.  the  net  effectiveness  of  this  single  ship  is  somewhere  between  60% 
and  0%;  probably  closer  to  zero  since  the  pilot  house  unit  which  steers  the  ship  and  the 
CIC  unit  (the  combat  unit  which  fights  the  ship),  are  both  down  here  at  zero  and  the 
ship  is  effectively  out  of  the  battle. 

This  is  a  list  of  the  NURA  data  bases  that  we  have  gathered  to  date  at  Dahlgren. 
We  have  tied  to  collect  most  of  the  surface  combatant  classes  on  the  one  side,  and  most 
of  the  amphibious  assault  ship  classes  on  the  other. 

As  Captain  Jones  mentioned,  we  don't  have  plan3  to  gather  any  more,  although  if 
someone  submits  a  specific  requirement  and  the  necessary  funding,  we  can  go  off  and 
gather  it  for  them.  We  have  recently  completed  a  number  of  different  studies.  The 
first  one  should  be  in  distribution  around  the  first  of  the  year  and  the  others  should 
follow  shortly  thereafter.  AU  of  the  studies  to  date  have  been  very  simplistic  scenarios 
of  a  single  munition  versus  a  single  ship.  These  are  funded  applications,  and  we  intend 
to  continue  them. 

We  would  like  to  study  an  amphibious  assault  and  extend  the  single  munition 
against  a  single  ship  to  several  munitions  against  several  ships  in  an  amphibious  task 
force.  We  would  also  like  to  use  the  model  for  various  exercises,  and  establish  a  100% 
performance  base  line,  so  that  when  we  come  back  and  say  they  are  at  60% 
effectiveness,  we  can  explain  exactly  what  that  means.  As  far  as  further  developments 
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for  the  program  are  concerned,  we  have  a  fairly  short  wish  list.  We  would  like  to 
obtain  some  validated  and  corroborated  MOPP  degradation  data,  and  we  would  also  like 
to  get  the  mask  only  degradation  data,  which  is  needed  for  the  Navy. 

The  chemical  warfare  modeling  office  at  Dahlgren  is  extremely  small.  There  are 
three  people  full  time,  and  a  few  people  part-time  on  the  project,  and  none  of  us  are 
human  performance  experts.  We  would  like  to  bring  in  an  expert,  and  have  him 
evaluate  the  model  from  his  point  of  view  and  give  us  some  useful  input  from  that. 
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TASK  NETWORK  MODELING  AND  MICRO  SAINT 

APPLICATIONS  TO  HUMAN  PERFORMANCE  IN 
COMBAT  MODELING 


Presented  at  the  Conference  on 
Computer  Simulation  of  Human  Combat  Performance 

Lawrence  Livermore  National  Laboratory 
30  November  1988 

Dr.  Ron  Laughery 
Micro  Analysis  and  Design 
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ORGANIZATION  OF  THE  PRESENTATION 


Introduction  to  task  network  modeling  of  human 
performance 

Presentation  of  the  Micro  SAINT  computer  simulation 
language 

Presentation  of  some  of  the  related  Micro  SAINT  projects 

Discussion  of  how  task  network  modeling  concepts  can  be 
applied  to  incorporating  human  performance  variability  into 
combat  models 
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ADDRESS  BY  DR.  RON  LAUGHERY 


DR.  LAUGHERY:  What  I  am  going  to  be  talking  about  this  afternoon  basically  is 
going  to  be  a  technique  called  task  network  modeling,  which  has  kind  of  manifested 
itself  in  MicroSAINT  over  the  last  couple  of  years.  What  I  have  been  doing  for  about 
the  last  ten  years  is  working  on  human  performance  modeling,  and  the  work  at 
MicroSAINT  has  developed  out  of  this  effort.  What  I  hope  you  will  find  at  the  end  of 
this  presentation  is  that  the  MicroSAINT  model  is  really  a  very  nice  technique  for 
bridging  the  gap  between  human  performance  models  and  combat  models. 

I  would  like  to  cover  four  items  in  this  presentation  (see  figure). 

First,  I  want  to  give  everyone  an  introduction  to  what  I  mean  by  task  network 
modeling.  Second,  I  want  to  talk  about  the  MicroSAINT  computer  simulation  language, 
largely  because  that's  the  title  of  this  talk.  Thirdly.  I  want  to  talk  about  some  related 
MicroSAINT  projects.  One  is  very  closely  related  because  it  draws  a  nice  link  between 
combat  modeling,  human  performance  modeling,  and  ultimately  the  overall  picture  of 
system  performance  during  the  system  design  process.  Then  fourth,  time  permitting,  I 
want  to  talk  about  how  the  concepts  of  task  network  modeling  of  human  performance 
can  be  incorporated  into  combat  models. 

First,  let  me  try  to  cover  the  topic  of  task  network  modeling,  kind  of  set  the 
groundwork  as  to  what  is  meant  by  the  term.  Essentially,  'task  network  modeling* 
involves  the  decomposition  of  a  series  of  human  activities  into  a  set  of  discrete  tasks,  and 
then  defining  their  sequential  relationships  primarily  through  a  network.  Really 
nothing  more  magical  than  that.  In  essence,  we  are  going  to  take  what  a  human  docs, 
but  it  doesn't  have  to  be  human.  Tasks  can  be  all  sorts  of  things.  They  can  be  human 
tasks,  or  they  can  be  system  tasks.  The  first  thing  you  do  when  constructing  &  task 
network  model  is  you  break  the  process  down.  Some  of  the  kinds  of  models  we  have 
been  creating  include  one  for  an  M-60  tank  crew  on  a  one-on-one  engagement  with  an 
automated  target  recognition.  We  break  down  the  tasks  of  each  of  the  four  crew 
positions  so  we  have  what  everybody  is  doing  in  time  and  how  they  are  interrelated. 
We  have  compared  the  automatic  target  recognition  approach  with  the  manual  target 
recognition  approach,  and  evaluated  the  different  network  models  you  get.  This  allows 
you  to  play  the  "what  if*  game  in  performance.  Those  are  not  the  only  elements  of  a 
task  network  rraxlel.  Once  you  have  defined  your  network,  you  have  some  other 
homework  in  at  least  three  areas.  First,  you  have  to  define  obvious  think  time 
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component  task  so  you  can  determine  the  time  to  perform  each  task.  These  task  times 
will  drive  the  simulation.  Secondly,  you  want  to  look  at  the  effect  that  each  task  has  on 
other  tasks.  For  example,  when  one  task  involves  depressing  a  button,  that  button  would 
probably  initiate  a  series  of  activities  in  the  system,  the  hardware  response  to  that  button 
being  pushed.  The  task  could  also  involve  the  consumption  of  resources.  The  beginning 
of  this  task  uses  some  piece  of  equipment  that's  now  no  longer  available  to  the  other 
people  in  the  operation  you  are  simulating.  The  third  thing  you  must  define  is  the 
conditions  required  before  the  task  can  begin.  This  can  be  like  resource  availability: 
resource  in  terms  of  the  individuals  or  resources  in  terms  of  equipment,  etc. 

Now.  a  few  extra  words  on  task  network  models.  First,  they  are  really  designed  to 
be  represented  in  an  event  driven  simulation.  I  don’t  want  to  get  into  a  discourse  on 
different  types  of  simulations,  but  there  are  basically  two  kinds.  Our  model  is  event 
driven  where  the  beginning  of  a  task  is  dependent  on  the  completion  of  some  other  task, 
and  so  on  down  the  line,  but  the  events  make  the  simulation  clock  move  forward. 
Network  models  are  generally  designed  to  be  agreed  upon  models  as  opposed  to  frame 
models,  where  every  second,  or  ten  seconds,  or  two  hours,  you  evaluate  the  state  of  the 
system,  you  evaluate  the  passage  of  time  and  the  state  of  the  system  at  the  beginning  of 
that  frame  time  and  what  might  have  happened  during  that  frame  time.  Task  network 
modeling  is  like  most  network  models  in  that  they  provide  primarily  a  discreet  event 
time  simulation.  We  have  also  looked  at  incorporating  the  concepts  of  frame 
simulation,  or  incorporating  cur  network  models  into  frame  simulation,  which  is 
certainly  possible.  We  have  also  looked  at  incorporating  other  aspects  such  as  manual 
control  models. 

Another  important  aspect  of  task  network  modeling  is  the  level  of  detail  to  be  used. 
There  is  no  rule  that  says  how  far  down  you  have  to  go  in  your  decomposition,  whic’r  is 
good,  because  that  means  that  you  can  often  adjust  the  amount  of  work  that  you  hate  to 
do  to  the  amount  of  time  that  you  have  available.  As  I  indicated  earlier.  Task  Network 
Models  are  a  very  common  method  for  simulating  system  components.  You  can 
simulate,  ami  we  have  simulated,  a  whole  variety  of  system  types  using  the  Task 
Network  Modeling  approach.  In  fact,  it  is  safe  to  say  the  MicroSAINT  operation  is  used 
to  simulate  manufacturing  more  than  human  performance.  Really,  if  you  think  about  it 
any  system  that  you  can  decompose  into  a  series  of  activities  and  subactivities  can  be 
represented  with  a  task  network.  That’s  really  why  it’s  a  useful  approach  I  think  for 
developing  integrated  man-machine  simulations.  I  think  you  can  probably  see  where 
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TASK  NETWORK  MODELING 


Task  network  modeling  involves  decomposing  human  activity  into 
a  series  of  discrete  tasks  «nd  then  defining  their  sequential 
relationships  primarily  through  a  network. 


TASK  NETWORK  MODELING 


Once  a  network  is  defined,  the  following  additional  parameters 
must  be  identified  for  each  task: 

1.  Time  to  perform  each  task 

2.  The  effect  the  task  has  on  other  task  as  represented 
by  variable  manipulations 


3.  Conditions  required  before  the  task  can  begin 


TASK  NETWORK  MODELS 


Additional  Points 

Task  network  models  are  designed  to  be  represented  in  an  event- 
driven  simulation.  However,  they  can  also  include  continuous 
aspects  (e.g.,  manual  control).  They  can  also  be  incorporated 
into  frame-driven  simulations. 

The  level  of  detail  is  entirely  at  the  discretion  of  the  user. 

Task  network  modeling  is  also  a  common  method  for  simulating 
other  system  components.  Therefore,  it  is  a  useful  approach  for 
developing  integrated  man-machine  simulations. 
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that’s  going  to  lead  to  in  this  talk  in  terms  of  how  combat  modeling  might  be  able  to  use 
task  networks.  With  this  kind  of  network  model  and  within  this  framework  you  can 
get.  as  1  say.  a  very  rigorous  model  of  the  whole  system,  not  just  the  human. 

MicroSAINT  has  gotten  some  interest  over  the  past  couple  of  years  in  terms  of 
being  a  tool  for  human  performance  modeling,  and  a  tool  for  test  network  modeling. 
MicroSAINT  is  a  tool,  not  a  model,  per  se.  like  the  optimal  control  model  or  the  AURA 
model.  What  MicroSAINT  is,  is  a  tool  for  developing  network  simulations.  What  I 
want  to  cover  in  the  discussion  of  MicroSAINT  basically  is  three  things.  On*  is  a  little 
bit  about  the  philosophy  behind  it  because  that  is  kind  of  important.  Seoonct,  a  very 
quick  history  of  the  tool,  and  then  finally  I’ll  run  through  some  of  the  computer 
screens. 

When  I  started  developing  MicroSAINT  and  doing  some  of  the  early  work,  one  of 
the  things  that  occurred  to  me  that  I  wanted  to  change  in  the  world  of  computer 
simulation  is  the  concept  that  developing  computer  simulations  really  does  not  need  to 
be  a  black  art.  I  have  had  the  feeling  over  the  years  that  people  luve  made  the  science  a 
lot  more  difficult  than  it  needed  to  be.  I  had  used  computer  simulation  through 
undergraduate  and  graduate  school  and  I  never  thought  it  needed  to  be  as  complicated 
as  it  seemed  to  be.  Why  then  is  computer  simulation  and  modeling  still  perceived  to  be 
a  relatively  complex  process?  The  reason  is,  I  believe,  complex  systems  really  can  not  be 
explored  deterministically  under  dynamic  operating  conditions.  I  think  you  are  seeing 
that  in  the  conference  here  today.  We  are  no  longer  talking  about  simple  equations  or 
simple  algorithms  which  link  combat  performance  to  this  whole  host  of  variables  in  a 
combat  environment.  There  are  just  too  many  things  going  on.  So  we  really  need 
simulation. 

The  argument  I  have  made  for  a  long  time  is  that  systems  analysis  is  really  a  very 
standard  procedure  during  system  design.  We  really  do  most  of  the  system 
decomposition,  and  I  would  argue  that  that’s  probably  the  hardest  part.  So  what  is  it  or 
what  has  it  been  that  has  kept  computer  simulation  of  human  performance  from 
becoming  a  fairly  common  practice?  1  think  the  answer  basically  is  in  the  tools  that 
have  been  available,  and  this  is  where  MicroSAINT  comes  into  it.  Basically  the  tools 
that  have  been  available  have  been  very  primitive.  Up  un'il  recently  if  you  needed  to 
develop  a  simulation,  what  you  did  was  call  in  the  simulation  experts,  explain  your 
problems  to  them,  they  would  come  back  a  couple  weeks  later  and  give  you  the 
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simulation.  That  approach  had  a  whole  host  of  problems  associated  with  it.  For  a  while 
I  wrestled  with  the  question,  'does  this  need  to  be  the  case?"  and  I  came  up  with  what  I 
think  is  an  appropriate  metaphor,  the  computerized  spread  sheet. 

Up  until  about  1981  only  computer  programmers  could  do  financial  kinds  of 
analysis  on  a  computer,  and  then  Visicom  appeared  on  the  scene  and  then  all  of  a 
sudden  anybody  could  do  financial  analysis  on  the  computer.  All  they  had  to  do  is 
understand  the  problem.  What  they  did  is  they  brought  the  computer  capability  closer 
to  the  people  that  had  the  problem.  1  think  the  same  thing  is  true  of  simulation,  and 
what  we  really  need  is  a  tool  to  bring.  So  with  that  direction,  we  have  developed 
MicroSAINT.  The  history  of  the  development  started  with  an  ARI  project  in  the  early 
80’ s.  1  got  interested  in  this  idea  of  a  spread  sheet  like  modeling  tool  and  in  the  mia-80’s 
we  won  a  contract  with  the  Joint  Worxing  Croup  on  Drug  Dependent  Degradation 
(JWG-D3)  and  Military  Performance.  They  wanted  to  map  the  effects  of  drugs  onto 
real  iife  performance,  but  they  didn’t  want  to  do  that  by  going  out  and  running  tank 
crews  off  the  edges  of  cliffs  after  they  gave  them  enough  drugs.  So  what  they  wanted 
to  do  was  build  a  simulation  tool,  build  a  bridge  between  performance  as  measured  in 
the  laboratory  and  performance  as  predicted  in  the  field.  In  about  a  year  we  developed 
a  Beta  test  version  and  in  late  ’85  we  delivered  version  2.0,  which  was  the  first  working 
version  of  MicroSAINT.  I  won’t  go  through  all  the  iterations,  but  basically  the  tool  has 
progressed. 

I  was  surprised  this  morning  to  find  out  that  MicroSAINT  is  being  used  in  the 
Navy.  It  has  found  its  way  into  a  lot  of  places,  which  I  think  is  good  news,  because  it 
will  promote  the  use  of  simulation  more  than  we  have  been  in  the  past.  MicroSAINT 
has  been  specifically  designed  for  modeling  human  machine  systems.  Even  though  it’s 
applicable  to  other  problems,  it  was  built  around  the  human  performance  problem,  so  I 
think  that  helps.  It  has  been  shown  to  be  easy  to  learn.  We  are  able  to  train  people; 
people  with  no  experience  in  simulation  on  how  to  use  this  thing  in  a  couple  of  days. 

Now,  let  me  talk  a  little  bit  about  the  technology.  It’s  a  military  product,  so  it’s 
available  to  all  military  organizations.  The  technology  behind  it  is  IBM  PC  based,  but 
highly  portable.  Under  Bob  Mills’  sponsorship,  we  have  ported  the  thing  to  a  VAX  as 
part  of  the  generic  systems  analyst  work  station  at  Wright  Patterson  Air  Force  Base. 
MicroSAINT  has  a  rather  large  model  capacity.  I  don’t  know  if  it  would  work  for  those 
huge  force  on  force  combat  models  or  an  IBM  PC.  but  certainly  we  have  not  run  into 


THE  PARSER  IN  MICRO  SAINT 


An  advanced  software  component,  known  as  a  parser  has  beerr 
embedded  within  Micro  SAINT. 

The  parser  permits  the  user  to  develop,  essentially,  detailed 
computer  code  within  the  model 

At  every  menu  location  followed  by  a  semi-colon,  a  set 
of  program  statements  in  a  C-like  programming 
language  can  be  included 

However,  this  code  is  stored  in  a  database  and,  as  the  simulation 
executes,  the  expressions  are  "parsed**  and  executed 

Essentially,  it  is  an  embedded  programming  language 
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MANPRINT  Products 


ARI  Contract 

6  Products 

Micro  SAINT  is  the  soul  of  3  of  the  six  products. 


constraints  in  modeling  human  performance  for  small  groups  performing  their  tasks  in  a 
combat  environment. 

Tuere  are  three  basic  things  that  you  do  with  any  model.  One  is  you  develop  it, 
secondly,  you  execute  the  model,  run  it.  and  collect  data  with  it,  and  third,  you  analyze 
the  results.  This  is  where  the  action  is.  Since  it's  a  software  tool  and  the  focus  is  on 
usability,  we  have  utilities  for  merging  and  organizing  files.  We  have  incorporated  a 
capability  that  we  call  "parser."  Parser  essentially  let’s  you  build  detailed  computer 
code  within  the  model.  It’s  stored  in  the  data  base  and  as  the  simulation  executes,  the 
simulations  are  parsed  and  executed.  This  has  turned  out  to  be  pretty  handy.  Now,  to 
summarize  the  features;  MicroSAINT  has  been  designed  for  the  user  of  simulation 
results  rather  than  the  simulation  expert.  We  have  really  tried  to  bring  that  into  the 
world  of  users.  It  is  completely  menu  driven  with  a  consistent  user  interface.  It 
provides  on  line  help,  and  it’s  easy  to  use  by  the  user  with  little  background  and 
computer  experience.  We  have  discovered  that  MicroSAINT.  like  SAINT,  which  is  an 
earlier  task  network  modeling  language)  is  much  more  powerful  than  it  was  originally 
anticipated.  While  its  focus  is  on  human  performance  modeling,  I  want  to  reiterate  it 
has  turned  out  to  be  a  reasonably  powerful  tool  for  other  types  of  systems. 

With  that  I’ll  leave  MicroSAINT  and  talk  about  two  projects  that  we  are  doing 
using  the  tool.  Essentially  what  we  have  done  is  taken  MicroSAINT  and  built  software 
around  it.  We  have  two  contracts  that  I  think  are  relevant  to  this  situation.  One  is  a 
development  for  the  Army’s  MAN  PRINT  program,  and  second  is  integration  of 
MicroSAINT  and  HOS.  HOS  was  referenced  earlier  as  the  Human  Operator  Simulator. 
HOS  vas  a  very  much  "bottom  up"  project,  while  MicroSAINT  is  top  down.  In 
MicroSAINT  you  build  from  the  top  and  you  break  it  down  as  far  as  you  need  to  go. 
HOS  started  at  the  bottom  where  you  had  micromodels  that  you  then  had  to  built  up. 
We  are  trying  to  integrate  those  two  products  so  for  human  performance  modeling  you 
can  go  either  way. 

First  let  me  talk  about  the  MANPRINT  program.  I  don’t  want  to  get  into  a 
discussion  of  the  MANPRINT  products  themselves,  but  rather  tell  you  how  Micro 
SAINT  is  being  used  in  the  program.  The  important  thing  here  is  that  Micro  SAINT  is 
the  soul  of  three  of  the  six  MANPRINT  products.  In  essence,  what  the  MANPRINT 
program  is  trying  to  do  is  to  tie  manpower,  personnel  and  training  issues  (MPT)  to 
system  performance.  In  other  words,  they  want  to  know  what  the  impact  is  going  to  be 
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APPROACH 


To  tie  system  performance  to  MPT  concerns 
using  quanti*atively>oriented  software  tools. 

To  consider  human  performance  in  the  context 
of  system  performance. 


The  focus  is  on  tying  the  effects  of  MPT  on 
human  performance  to  system  performance. 


MANPRINT  Tools 


PC  -  based,  automated  decision  aids 

User-friendly 

Menu-driven 

On-line,  context-specific  help 

Based  on  computer  simulation 
Allows  "what-if*  comparisons 
Create,  execute,  store,  compare  multiple  scenarios 

Divided  into  two  types  of  products 
Pre-design  forecasting  tools 
Design  evaluation  tools 
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MANPRINT  Tools 


1.  System  Performance  &  RAM  Criterion  Estimation  Aid  (SPARC) 

2.  Manpower  Constraints  Estimation  Aid  (M-Con) 

3.  Personnel  Constraints  Estimation  Aid  (P-Con) 

4.  Training  Constraints  Estimation  Aid  (T-Con) 

5.  Manpower-based  System  Evaluation  Aid  (Man-seval) 

6.  Personnel-based  System  Evaluation  Aid  (Per-seval) 
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on  a  system  if  there  is  not  enough  people  to  man  it.  if  the  people  aren’t  of  the  right 
type,  and  if  they  don’t  receive  enough  training.  We  are  under  contract  to  the  Army  to 
develop  a  series  of  very  quantitatively  oriented  software  tools,  the  focus  of  which  is  to 
try  to  link  MPT  effects  to  system  performance.  They  are  all  going  to  be  microcomputer 
based,  and  user  friendly. 

The  purpose  of  SPARC  (System  Reference  &  RAM  Criterion  Estimation  Aid)  is  to 
take  either  a  mission  level  requirement  or  a  function  level  requirement,  and  decompose 
it  down  into  task  level  requirements  using  a  budget  process.  They  want  to  make  sure 
that  all  the  tasks  add  up  fc  the  mission  level  requirement  if  you  set  time  and  accuracy 
requirement  at  the  mission  level.  They  don’t  want  to  design  a  bunch  of  tasks  that  aren’t 
going  to  allow  you  to  meet  system  requirements.  The  second,  third  and  fourth  products 
shown  in  the  above  figure  I  am  not  going  to  talk  about  here.  Essentially  they  play  a 
zero  sum  game  with  numbers  of  people,  types  of  people  and  amount  of  training.  You 
^et  constraints  about  how  much  training,  what  type  of  people,  etc..  Then  the  fifth  and 
sixth  products  are  post  design  tools.  I  think  the  important  thing  is  to  see  how  these 
things  all  fit.  The  post  design  tools  are  what  you  use  to  see  if  the  requirements  that  you 
initially  defined  were  met  after  the  system  was  completed. 

Let  me  just  make  a  point  through  showing  you  the  process  of  how  these  things  are 
supposed  to  fit  into  the  system’s  acquisition  process.  The  whole  system’s  acquisition  was 
supposed  to  be  driven  by  mission  area  analysis.  Amongst  the  things  that  go  into  the 
mission  area  analysis  are  the  combat  model  results.  The  combat  model  is  presumably 
what  tells  you  that  you  have  got  a  threat  out  there  that  hasn’t  been  dealt  with 
effectively  and  we  have  got  to  do  something  about  it.  The  analysis  should  tel*  us  we 
have  got  to  design  a  system  that’s  faster  or  mere  accurate  or  whatever  it  is  to  meet  the 
threat. 

Now.  there  are  three  things  I  want  to  bring  up  with  respect  to  the  MANPRINT 
project.  First  of  all,  as  far  as  1  know,  this  is  one  of  the  first  serious  attempts  at  linking 
the  combat  modeling  process  with  system  development.  The  combat  modeling  process 
drives  everything  we  do  all  the  way  through  to  the  end  of  the  system  design.  At  every 
point  in  the  development,  designs  are  always  evaluated  against  the  simulation  model 
requirements.  The  second  thing  is  that  wo  have  tried  to  embed  performance  shaping 
functions  in  some  of  these  products.  We  are  trying  to  include  some  of  the  stressors 
associated  with  MOPP  and  sleep  deprivation,  aa  well  as  personal  characteristics.  The 
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third  thing  about  the  MANPRINT  program  is  that  as  part  of  the  project  we  are 
developing  some  very  extensive  combat  simulation  data  libraries.  We  have  test  network 
models  that  incorporate  human  performance  models  for  20  plus  Army  systems.  This 
library  of  models  will  allow  researchers  to  build,  modify  and  refine  existing  systems  as 
new  human  performance  information  is  developed. 

Our  second  major  piece  of  related  work  is  the  MicroSAINT  HOS  integration.  HOS 
really  works  from  the  bottom  up.  where  you  have  a  rather  detailed  model  of  basic 
activities  such  as  decision  making  for  hand  movement.  If  you  compare  that  to 
MicroSAINT  where  you  start  out  with  the  individual  task  level,  you  kind  of  see  where 
those  two  things  can  meet  in  the  middle.  In  the  ideal  environment,  what  will  happen  is 
MicroSAINT  or  the  task  network  model  will  be  the  overall  software  driver,  and  from 
that  you  will  call  a  function  library,  which  will  bring  in  and  let  you  build  up  the 
performance  time  estimates  and  performance  accuracy  estimates  using  some  of  these 
human  performance  micro-models.  This  will  allow  you  to  develop  the  overall  task 
performance  estimates.  That  pretty  much  concludes  our  ongoing  work. 

I  would  now  like  to  talk  a  bit  about  how  I  think  the  task  networking  model  can  be 
used  to  incorporate  human  performance  variability  into  combat  models.  The  key  pert 
of  the  phrase  here  is  that  we  really  want  to  incorporate  human  performance  variability 
We  don’t  really  need  to  include  detailed  human  performance  in  all  combat  situations, 
but  by  not  putting  any  model  in  there  to  represent  variability  of  the  human  associated 
with  whatever  elements  of  the  battlefield  are  going  to  affect  his  performance  (as  Dr. 
Kolpcic  indicated)  assumed  a  model  value  of  one. 

I  certainly  don’t  want  to  make  the  case  that  we  need  to  get  down  there  in  the 
severe  details  of  things.  In  fact.  I  have  a  fear  that  when  people  think  of  human 
performance  modeling  and  combat  models,  they  think  of  what  I  call  the  “blue  socks 
syndrome."  which  is  an  idea  given  to  me  by  a  modeler.  He  indicated  that  he  wo*. Id  go 
out  to  a  manufacturing  facility  and  develop  what  he  thought  was  a  very  good  model, 
covering  everything  he  needed  to  cover.  He  would  take  it  in  to  the  manager  and  show 
him  the  model,  and  the  manager  would  say.  "Yeah,  but  what  happens  if  the  guy  wears 
blue  socks?"  Somehow  my  modeler  friend  didn’t  think  that  was  very  important.  I  don’t 
think  that’s  very  important  either  and  I  don’t  think  we  are  going  to  be  modeling  guys  in 
the  battlefield  wearing  blue  socks,  and  that  we  shouldn’t  get  down  to  that  level  of 
detail. 


189 


What  we  need  to  concentrate  on  are  those  things  that  affect  human  performance  as 
they  relate  to  a  particular  modeling  application.  Let’s  get  those  in  the  models.  Let’s 
incorporate  those  aspects  of  variability  that  make  a  difference.  As  I  see  it  there  are 
three  ways  of  using  task  network  modeling  in  combat  models.  First,  we  can  decompose 
human  tasks  within  a  combat  model  into  more  finely  detailed  task  networks.  Second,  we 
can  develop  performance  shaping  functions  for  relating  performance  to  oth  -  r  variables, 
primarily  combat  stressors.  Third  you  can  develop  the  task  networ .  models  as 
independent  stand  alone  modules,  or  as  integral  parts  of  the  overall  model.  All  three  of 
those  are  independent  of  one  another.  You  can  take  these  in  any  kind  o*  combination 
that  you  need. 

Summary  points:  Task  network  analysis  provides  a  basic  framework  and  a  bridge 
for  incorporating  human  performance  variability  into  combat  simulation. 

There  is  existing  simulation  software  to  make  incorporating  human  performance  data 
feasible.  There  are  at  least  three  approaches  for  incorporating  human  performance 
variability  into  combat  models:  Decompose  human  task  with  the  model;  develop 
performance  shaping  functions;  and  conduct  human  performance  simulation  external  to 
the  combat  simulation  model.  Bottom  line  is  that  there  probably  is  not  a  right  approach 
to  cover  all  questions.  It  really  depends  on  the  combat  model  involved.  For  some 
levels,  we  may  want  to  do  one  thing,  and  for  other  levels  we  may  want  to  use  another 
approach.  Tnere  is  not  going  to  be  a  single  answer. 
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APPLYING  THE  CONCEPTS  OF  TASK  NETWORK  MODELING  TO 
INCORPORATING  HUMAN  PERFORMANCE  VARIABILITY  INTO 
COMBAT  MODELS 

Key  part  of  that  phrase  Is  "incorporating  human  performance 
variability." 


We  don’t  need  to  include  detailed  human  performance 
models  in  all  combat  simulations,  but  we  should  strive 
to  represent  the  variability  of  human  performance  in 
these  models  as  it  will  significantly  affect  the  outcome. 


ALTERNATIVE  WAYS  OF  INCORPORATING  HUMAN 
PERFORMANCE  VARIABILITY  INTO  COMBAT  MODELS  FROM 
THE  PERSPECTIVE  OF  TASK  NETWORK  MODELING 


Three  basic  sets  of  alternatives: 

1.  Decompose  human  tasks  within  a  combat  model  into 
more  finely  detailed  task  networks 

2.  Develop  performance  shaping  functions  for  tasks  within 
combat  models  relating  performance  to  other  variables 
of  interest  (e.g.t  combat  stressors) 

3.  Conduct  human  performance  simulations  external  to 
the  combat  model  and  set  combat  model  parameters 
reflecting  the  outcomes  of  these  simulations. 


Ail  three  of  these  are  independent  of  one  another 
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DEVELOP  DETAILED 
TASK  NETWORKS 


COMBAT  MODEL 


SUMMARY 


Task  network  modeling  provides  a  basic  framework  for 
incorporating  human  performance  variability  into  combat 
simulation 

Existing  simulation  software,  such  as  Micro  SAINT,  make 
the  incorporation  of  task  network  modeling  mere  feasible 

Within  this  framework,  there  are  at  least  three  approaches 
that  can  be  included  singularly  or  in  combination 

The  right  approach  will  depend  upon  the  questions  being 
addressed  by  the  combat  model  -  there  is  no  single  answer. 


MR.  BANKS:  Thank  you.  Before  I  introduce  the  next  speaker.  I  would  like  to 
mention  a  new  technology  called  Intelligent  Gateway  Processing  (IGP).  What  this 
technology  allows  one  to  do  is  to  talk  with  any  computer  regardless  of  its  architecture, 
operating  system  or  physical  location.  That  sounds  like  a  rather  big  statement,  but  in 
fact  it’s  true.  One  of  the  problems  we  have  seen  in  the  Navy  and  the  Air  Force  is  that 
they  are  forced  to  procure  lots  of  different  types  of  machines,  and  these  machines  are 
not  easily  interconnectable.  These  machines  don't  talk  to  each  other.  For  example,  it  is 
difficult  for  a  Hewlett  Packard  to  talk  to  a  Data  General,  and  it  is  difficult  for  a  Data 
General  to  talk  to  an  IBM.  etc.. 

What  a  Gateway  essentially  allows  one  to  do  is  sit  in  your  office  and  hook  up  to  150 
different  computers.  It’s  a  table  driven  interpreter  that  stores  all  the  protocols  of  all 
the  other  host  machines  that  you  wish  to  talk  to.  Through  the  interpreter  you  talk  in 
your  language  for  your  PC  and  it  converts  it  to  the  target  host  that  you  are  trying  to 
connect  to.  So  you  don't  have  to  know  the  system's  command  language  of  the  down  line 
host.  What  this  has  an  implication  for  is  remote  com  tat  simulation  modeling.  I  can 
have  a  model  here  at  Livermore  and  give  access  to  it  to  the  Army.  Navy.  Marine  Corps. 
TRW.  and  General  Electric  without  their  physically  having  to  have  that  hardware  and 
software  running  at  their  site. 

Another  scenario:  let's  say  you  are  sending  troops  on  a  combat  mission.  Weather 
changes,  enemy  strength  changes  because  of  new  updated  intelligence.  You  could  play 
the  game  on  a  C-130  as  you  are  flying  into  the  combat  zone.  You  could  actually  go 
through  one  last  review  of  the  operation  before  you  come  in.  That’s  real  time  combat 
simulation  modeling. 

The  reason  I  am  mentioning  it  to  you  is  that  over  the  break  I  realized  that  a  lot  of 
people  were  not  aware  of  the  IGP  technology.  It's  about  five  years  old;  the  Air  Force 
has  embraced  it.  the  Air  Force  Logistics  Command  now  has  installed  31  Gateways.  NASA 
has  installed  14,  and  a  few  other  government  agencies  have  ordered  them. 
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MR.  HAWKINS:  I’m  going  to  talk  about  SHIPDAM  (Ship  Damage  Model),  a 
model  that  the  Navy  has  been  using  for  the  last  two  or  three  years.  It’s  not  fully 
documented  yet  and  probably  won't  be  for  a  while,  but  it’s  a  simple  vulnerability  model 
for  surface  ships. 

I  am  from  David  Taylor  Research  Center.  We  are  a  Navy  lab.  We  are  what  used 
to  be  called  the  David  Taylor  Model  Basin.  I  work  in  the  structures  department  at 
David  Taylor,  and  my  division’s  work  is  primarily  in  surface  ship  vulnerability. 

The  main  tools  that  we  u«e  have  been  developed  over  the  last  15  or  20  years  and 
include  the  Ship  Vulnerability  Model  (SVM),  and  the  Soviet  Ship  Vulnerability  Model 
(SSVP).  Ship  vulnerability  model  is  for  U.  S  ships  attacked  by  Soviet  weapons.  The 
soviet  ship  model  is  just  the  opposite.  To  give  you  a  little  picture  of  what  goes  into  the 
SVM  before  I  get  into  SHIPDAM.  I  have  included  the  following  figure.  There  is  a  lot 
of  input.  The  ship  is  described  in  great  detail,  plate  by  plate  almost,  and  components 
are  modeled,  in  some  cases  down  to  consoles  in  various  compartments. 

We  combine  the  vital  components  to  form  systems,  we  combine  systems  to  form 
mission  areas,  and  combine  mission  areas  ro  perform  overall  readiness  approximations. 
The  attack  parameters  of  Soviet  weapons  are  input  using  whatever  intelligence  data  we 
can  get.  The  physics  that’s  gone  into  the  damage  mechanisms  is  based  on  World  War  II 
data,  what  we  derived  from  war  damage  reports.  Much  of  it  is  theoretical.  The  output 
finally  is  the  effect  on  the  system  readiness  and  vital  components  as  a  function  of 
number  of  hits.  When  we  use  this  model  we  do  a  large  number  of  trials,  a  Monte  Carlo 
p.^Tessment. 


The  next  figure  is  an  example  of  how  the  vital  components  are  connected  h.  order 
to  ouild  a  system.  In  this  case  you  will  notice  everything  that’s  in  series  is  vital.  If  any 
one  of  those  go  down,  the  system  is  considered  down.  The  two  motor  generator  sets  are 
in  parallel,  so  you  would  have  xo  lose  both  of  thosa  to  lose  the  function  of  that  mission. 

The  next  figure  deals  with  the  C3  function.  I  think  probably  most  of  you  all  are 
familiar  with  the  C3  readiness  designation.  That  roughly  equates  to  50%  performance  of 
the  ship  in  its  mission  areas,  and  we  use  the  system  descriptions  to  form  a  C3  diagram. 
Anything  linked  in  series  is  vital.  A  representation  of  how  the  hit  distributions  for  these 
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STRUCTURES  DEPARTMENT 

SURFACE  SHIP  PROTECTION  DIVISION 


•  SURVIVABILITY/VULNERABILITY 
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ARRANGEMENTS 
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SSVP 

SOVIET  SHIP  VULNERABILITY 


weapons  is  input  to  the  SVM  is  shown  in  the  next  figure.  This  is  critical  stuff  and  this 
is  what  we  know  the  least  about.  I’ll  get  into  that  after  a  while.  As  I  said,  it’s  a  Monte 
Carlo  technique.  We  run  a  lot  of  trials,  with  a  number  of  iterations,  and  come  up  with 
expected  values. 

This  next  figure  shows  a  little  bit  of  how  the  results  would  look.  This  is  typical, 
but  not  representative  of  any  particular  ship.  As  you  can  see,  we  have  the  number  of 
hits,  and  the  probability  of  a  mass  detonation,  which  is  an  important  event  in  our 
assessments,  because  it  generally  results  in  the  ship  sinking  and  then  the  effect  on 
various  mission  areas,  and  these  are  combined  to  determine  overall  readiness  in  the  last 
two  columns. 

The  next  figure  shows  a  few  of  the  recent  applications  that  SVM  has  been  used  for. 
This  includes  SSVP  applications  as  well.  The  cost  of  SVM  is  very  high.  It  takes  a  long 
time  to  model  a  ship  in  the  required  detail,  and  it  takes  a  long  time  to  run  the  program 
to  get  the  results.  The  SVM  is  an  engineering  design  tool,  and  it's  appropriate  that  it 
should  be  detailed,  but  it  proves  not  to  be  especially  appropriate  for  war  gamers  to  use. 
particularly  the  Center  for  Naval  Wargaming  (CNW)  up  at  Newport.  The  people  at 
CNW  came  to  us  and  asked  us.  to  make  a  short  version  of  SVM,  something  they  could 
use  on  line  perhaps,  that  would  give  them  answers  to  provide  the  players  with  when  hits 
occur  on  ships  during  the  war  games. 

The  difficulties  that  they  found  with  models  that  we  had  traditionally  used  was 
that  they  had  to  rely  on  look  up  tables  rather  than  being  able  to  go  in  and  take  the 
damage  of  a  particular  hit  at  a  particular  time.  The  data  bases  were  incomplete.  We 
haven’t  modeled  every  ship  at  the  level  of  detail  required  by  those  two  bigger  tools,  and 
they  are  inconsistent.  The  SSV,  SVM  and  SSVP  won’t  produce  the  same  answers 
because  they  arc  not  designed  to  evaluate  the  same  way.  We  have  a  conservative  bias  in 
each  of  these  models. 

For  the  TVM  we  are  conservative  on  the  side  of  protecting  the  ship,  for  the  SSVP 
we  are  conservative  in  that  we  are  designing  weapons  to  defeat  Soviet  ships.  So  the  two 
models  (if  they  were  used  on  the  same  ship)  would  produce  different  results.  That 
wasn’t  right  for  the  war  games.  They  wanted  a  totally  consistent  data  base.  Maybe  not 
as  detailed,  maybe  not  as  precise,  but  at  least  evaluating  each  size  ship  to  the  same  set  of 
standards.  The  SVM,  because  of  the  large  number  of  runs  we  do,  can’t  do  weapon 
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mixes.  In  a  war  game  you  can  get  hit  by  a  torpedo  and  then  by  a  missile,  and  there 
would  be  no  way  to  run  the  SVM  enough  times  to  produce  those  sort  of  values. 

Because  of  these  programs  CNW  funded  development  of  SHIPDAM.  SHIPDAM  is 
baaed  on  the  SVM  and  SSVP  practices.  What  I  did  was  to  simplify  all  the  descriptions 
and  the  algorithms  and  tuned  it  as  I  simplified  the  algorithms.  I  ran  SHIPDAM  a 
number  of  times  and  compare  it  tc  a  similar  nin  in  the  bigger  model.  I  tuned  its  results 
to  get  within  15%  to  20%  of  the  big  model.  We  know  that  the  externals  of  the  ship 
pretty  much  define  what  the  internals  are.  Ship  design  hasn’t  changed  a  whole  lot.  You 
can  make  a  lot  of  assumptions  that  are  going  to  be  pretty  close  to  right  just  by  looking 
at  the  outside  of  the  ship. 

In  the  simulation  at  CNW  the  users  generate  weapon  hits  against  particular  ships. 
The  users  can  indicate  where  they  hit  the  ship.  They  may  or  may  not  generate  the  first 
point.  If  they  don't,  we  have  included  in  SHIPDAM  the  ability  to  apply  those  hit 
distributions  that  we  use  in  the  bigger  models  and  come  up  with  the  impact  generator 
for  their  use. 

The  output  of  SHIPDAM  is  whether  or  not  the  ship  is  sunk,  what  weapon  systems 
work,  how  the  mobility  of  the  ship  is  affected  after  the  hit.  and  how  much  flooding  has 
occurred. 

I’ll  quickly  go  through  what  SHIPDaM  looks  like.  It  consists  of  four  parts:  the 
burst  point  generator  (BPG).  a  weapon  data  file  (WEP),  the  BDA  which  is  the  ship 
description  data,  and  SHIPDAM  algorithms. 

(1)  The  BPG  is  a  very  simplified  structural  geometric  representation  of  the 
ship.  All  it’s  there  for  is  to  tell  the  weapon  that  it’s  encountered  the  ship  so  the 
weapon  knows  what  it’s  dealing  with.  Included  in  it  are  aim  points  for  the 
various  guidance  systems  that  are  part  of  the  weapons  data  base. 

(2)  Weapons  (WEP)  input,  is  also  a  very  short  file.  As  shown  in  the  next 
figure,  it  consists  of  two  simulation  symbols,  the  azimuth  and  -.levation  angle 
of  attack  for  the  particular  weapon.  We  also  include  the  velocity,  type  of 
weapon,  whether  it’s  a  missile  or  torpedo,  guidance,  the  fusing  delay  or 
proximity,  a  couple  of  sequences  related  to  hit  distribution  if  we  know  enough 
to  include  one  of  those,  and  its  SA3  or  delayed  action  fuse. 
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•  SENSITIVITY  STUDIES 

•  FUSE  DELAY,  BLAST  DAMAGE.  SHOCK  DAMAGE,  MASS  DETONATION, 
SEAWORTHINESS,  VC  LOCATIONS,  ELECTRIC  WIRING,  FIRE  SPREAD, 
PROTECTION  FEATURES.  STATISTICAL 


SVM  &  SSVP  PROBABILITIES 
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(3)  The  BDA  program  tells  us  what  algorithms  to  apply  for  that  weapon,  the 
charge  weight,  and  if  it's  a  jet  weapon.  If  it  is  a  jet  weapon,  put  in  a  jet  length 
and  diameter.  I  don’t  try  to  model  the  interaction  of  the  jet  with  the  ship’s 
structure.  For  most  ships  and  most  large  jet  weapons,  it  will  just  penetrate 
clean  through.  The  BDA  file  is  the  file  that  contains  each  of  the  vital  zones.  I 
don’t  model  vital  components  in  the  same  way  the  SVM  does.  I  model  a  zone 
in  a  ship.  For  instance,  a  radar  system  in  my  model  will  just  be  an  antenna,  a 
wave  guidance  is  a  simple  volume.  A  wave  guide  and  a  volume  of  space 
roughly  under  that  mast  will  be  approximately  the  same  volume  as  the  radar 
room,  the  associated  fan  room,  or  whatever  electronic  cooling  rooms  might 
have  been  associated  with  that  antenna. 

(4)  The  SHIPDAM  projects  being  worked  on  now  are  an  attempt  to  include 
personnel  casualties  in  the  model,  and  hopefully  to  provide  something  for  the 
war  college  that  will  tell  them  how  long  after  they  take  damage  to  the  systems 
it  will  take  to  get  them  back  up.  That  has  become  a  pretty  big  question  when 
they  are  doing  the  games.  There  is  an  outfit  in  Philadelphia  called  NAVSHIPS 
that  tabulates  the  manufacturing  lead  times  and  availability  of  parts,  and  I 
think  we  can  connect  that  and  have  values  on  each  vital  component,  that  will 
give  a  rough  indication  of  how  long  it  would  take  to  replace  them. 

SHIPDAM  has  never  been  placed  on  line  at  Newport.  I  think  the  new  system  of 
war  gaming  that  they  have  been  developing  and  hoping  that  SHIPDAM  would  integrate 
with  hasn’t  reached  the  development  phase  that  they  had  hoped  for.  They  currently  use 
SHIPDAM  off  line,  and  it  seems  to  have  satisfied  their  needs  for  now.  The  model  is 
still  very  visible.  When  a  carrier  sinks.  Admirals  show  up  at  the  SHIPDAM  desk  and 
ask  about  it. 

The  model  is  still  developmental,  and  I  am  adding  things  to  it  all  the  time.  This  is  a 
nice  feature.  The  model  is  very  flexible  and  easily  changed.  SHIPDAM  hasn’t  been 
documented  and  that's  been  intentional.  As  soon  as  I  document  it,  people  will  start 
using  it,  and  since  l  am  developing  it,  I  don't  want  people  to  use  it  unless  I  know  about 
it.  I  liave  never  held  it  out  to  be  accurate.  I  started  off  telling  people  it  would  be 
ancillary,  and  they  seemed  satisfied  with  that. 
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I  got  interested  in  modeling  casualties  because  at  some  of  the  war  games  I  observed 
I  saw  people  that  were  assessing  casualties  during  the  games.  They  had  some  tables  of 
killed  and  wounded  by  ship  class,  but  didn’t  have  it  by  weapon  class.  The  information 
they  were  using  was  a  rather  crude  estimation  made  from  World  War  II  data,  but  it 
was  very  incomplete.  Their  tables  didn’t  respond  to  the  particular  weapon,  they  didn’t 
respond  to  the  particular  ships,  and  they  only  included  large  ship  classes.  It  seemed  that 
since  we  already  had  the  ship  modeled  and  wc  already  had  the  compartments  on  the 
ships  modeled,  it  would  be  fairly  simple  to  include  people.  If  I  didn't  take  them  too 
seriously  and  if  I  treated  them  like  a  piece  of  equipment,  they  should  fit  right  into  the 
SHIPDAM  model.  It  seems  very  straightforward. 

At  David  Taylor  we  had  background  in  personnel  protection.  I  asked  Naval 
Medical  R&D  for  funding,  and  received  5K  to  do  a  quick  feasibility  study.  I  used  an 
PPG- 7  since  that’s  a  simple  ship  and  made  some  very  simple  algorithms  that  I  got  out  of 
readily  available  data,  and  then  did  hand  calculations  on  an  under  bottom  threat  and  a 
big  missile  threat,  and  the  numbers  came  out  looking  reasonable  at  that  time.  Nothing 
much  happened  for  a  while  after  that.  Then  the  Stark  and  the  Roberts  events  occurred 
and  they  checked  how  SHIPDAM  did.  both  for  the  equipment  damage  and  for 
personnel  killed  and  wounded,  and  again,  it  did  reasonably  well.  It  wasn’t  terribly  good 
on  the  personnel. 

On  the  Stark  the  people  were  not  where  they  were  supposed  to  be.  Cn  the  Roberts, 
my  algorithms  were  not  as  good  as  I  would  have  liked,  and  the  damage  control  officer 
on  the  Roberts  had  done  a  better  job  than  Navy  specs  called  for.  He  got  his  people  in 
better  readiness  condition  than  one  would  have  ever  guessed.  But  the  remits  did  match 
up  reasonably  well,  well  enough  to  encourage  some  of  the  people  in  the  Pentagon  to 
look  at  the  model  a  bit  more.  In  March  of  this  year,  the  Navy  got  concerned  about  its 
casualty  rates.  They  decided  that  they  needed  a  new  set  of  casualty  rates,  one  that 
would  be  auditable.  They  were  ready  to  go  out  with  an  RFP  to  private  industry.  It 
became  pretty  dear  that  for  at  least  the  Navy  afloat,  whoever  got  the  contract  would 
have  to  come  to  the  model  bases  to  get  ship  damage  assessment,  and  if  we  were  going  to 
be  imposed  on  that  much,  we  might  as  well  go  ahead  and  take  on  the  job.  So  we  did. 

The  program  calls  for  developing  casualty  statistics  for  four  categories  of  Naval 
personnel:  Personnel  afloat,  personnel  ashore  in  fixed  facilities,  personnel  ashore 
mobile,  and  personnel  with  the  Marines.  They  wanted  four  values:  killed  in  action, 


wounded  in  action,  missing-in-action  and  diseased  non-vital  injury.  We  have 
subsequently  added  a  new  category  for  the  Marines  on  Navy  ships.  The  Marines  didn’t 
account  for  them  and  neither  did  the  Navy.  Our  approach  has  been  to  document  wliat 
has  been  done  previously  and  to  develop  some  new  values  where  appropriate.  For  most 
of  the  needed  numbers  we  are  not  the  appropriate  facility  to  develop  them.  We  are 
appropriate  for  naval  personnel  afloat,  but  for  everything  else  we  have  had  to  identify 
other  organizations  where  the  information  is  available. 

A  lot  has  already  been  done  and  all  we  have  to  do  is  bring  it  together.  Bill  Pugh  at 
NHRC  has  been  working  with  DNBI  data.  He  has  been  funded  and  just  completed  that 
work.  The  Marine  Corps  has  just  gone  out  with  a  contract  to  update  their  values,  and 
we  will  use  their  values  for  Navy  personnel  with  the  Marine  Corps. 

For  the  ashore  fixed  site,  two  organizations  have  been  identified  so  far.  The  Air 
Force  has  asked  their  contractor  (BDM)  to  prepare  casualty  rates  for  Air  Force  bases. 
The  Naval  Civil  Engineering  Lab  at  Port  Hueneme  has  a  model  that  seems  to  be  fairly 
similar  to  SHIPDAM,  only  it  models  structures  rather  than  ships.  The  Navy  ashore 
model  is  a  catch-all:  about  10  or  12  different  constituencies  involved  that  don’t  have  very 
much  relationship  to  each  other.  We  will  probably  end  up  using  data  from  the  Army  or 
the  USMC. 

Our  procedures  assume  that  personnel  are  manning  their  general  quarters  stations. 
That’3  where  we  went  wrong  on  the  Stark.  Aboard  the  Stark,  nobody  was  at  general 
quarters  when  the  ship  was  hit  Most  people  on  a  ship  at  general  quarters  are  standing 
inside  what  1  have  previously  modeled  as  vital  zones.  They  are  standing  around 
equipment  that’s  necessary  to  make  the  ship  work.  The  only  personnel  that  we  need  to 
add  additional  locations  for  are  the  damage  control  parties.  That’s  important.  They  are 
usually  located  in  corridors  or  passageways  away  from  the  vital  components  currently  in 
the  model.  With  a  minimum  addition  of  vital  zones,  we  can  account  for  virtually  all 
the  people  on  board. 

I  have  put  in  some  injury  algorithms  and  we  are  working  to  improve  them  now. 
Since  SHIPDAM  runs  very  quickly,  I  will  be  able  to  run  any  ship  class  against  any 
weapon  type  a  large  number  of  times  in  a  few  minutes  and  get  expected  numbers  of 
killed  and  wounded.  The  next  figure  shows  you  what  the  casualty  data  looks  like.  I  can 
do  this  for  each  ship  class  and  each  primary  weapon  threat  type. 


ONGOING  DEVELOPMENT 


•  Personnel  -  Casualties 
(Killed  and  Wounded)  Based 
on  Manning  Document  Location 
of  Personnel  and  Shock  &  Blast 

•  Battle  Damage  Repair-  Times 
to  Acquire  and  Replace /install 
Equipment,  and  Repair  Facility 
Required  -  NAVSHIPSO,  Phila., 
is  Preparing  Data  to  be  entered 
into  SHIP  DAM 
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NEVER  PLACED  ’ON-LINE’ 

AT  WAR  GAMES 

USED  AS  OFF-LINE  PC  MODEL 
BY  GAME  UMPIRES 

VERY  VISIBLE 

STILL  DEVELOPMENTAL 

FLEXIBLE  ENOUGH  TO  RESPOND 
TO  NEW  REQUESTS 

NOT  FORMALLY  DOCUMENTED 

NEVER  HELD  OUT  AS  MORE 
’ACCURATE’  THAN  ’REASONABLE’ 


SHIPDAM  &  CASUALTIES 


•  DIFFICULTIES  WITH  CASUALTIES 
AT  WAR  GAMES 

•  PERSONNEL  NOT  THAT  DIFFERENT 
THAN  EQUIPMENT 

•  WEAPON  EFFECTS  AND  SHIPBOARD 
LOCATIONS  ALREADY  IN  PLACE 

•  DTRC  HAS  BACKGROUND  IN 
PERSONNEL  PROTECTION 

•  SEEMED  STRAIGHT  FORWARD 
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EVOLUTION 


•  MARCH  87 

-  $  5K  FEASIBILITY 

-  FFG-7 

-  SIMPLE  ALGORITHMS 

-  HAND  CALCULATION 

•  USS  STARK 

USS  SAMUEL  B  ROBERTS 

•  MARCH  88 

-  OP-813  (OP  932,  OP  601) 

-  NAVY  CASUALTY  RATES 

-  CONTRACTOR  TO  NAVY 
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PROBLEM  STATEMENT 


;  CURRENT  NAVY  METHODS  FOR 
|  ESTIMATING  CASUALTY  RATES: 


A.  WERE  NOT  SUFFICIENTLY 
DOCUMENTED  AND  AUDITABLE 

!  B.  DO  NOT  SATISFY  THE  NEEDS 
!  OF  ALL  POTENTIAL  USERS 

C.  DO  MOT  ALLOW  FLEXIBILITY 
FOR  ALTERNATIVE  THEATERS 
OR  NEW  WEAPONS,  TACTICS, 
AND  TARGETS 
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APPROACH 


•  DOCUMENT  TO  THE  EXTENT  POSSIBLE 
THE  EXISTING  CASUALTY  RATES 

•  DEVELOP  NEW  METHODS  FOR  PRE¬ 
DICTING  CASUALTY  RATES  AS  NEEDED 

1)  DOCUMENTED,  AUDITABLE  TRAIL 

2)  FLEXIBLE 

3)  SERVE  WIDE  VARIETY  OF  USERS 

•  IDENTIFY  AND/OR  COORDINATE  THE 
PROPER  APPROACH  FOR  PREDICTING 
RATES  FOR: 

1)  DISEASE  NON-BATTLE  INJURIES 

2)  FORCES  ASHORE 

3)  FORCES  WITH  MARINES 

•  DAVID  TAYLOR  RESEARCH  CENTER 
(DTRC)  WILL  DEVELOP  METHODS  FOR 
ESTIMATING  CASUALTY  RATES 


CASUALTY  RATES 


DNBI  *  MR.  BILL  PUGH  NHRC 
VV/USMC  »  USMC 

ASHORE  (FIXED  SITE)  -  AF  (BDM)  OR 

NOEL 

ASHORE  (MOBILE)  *  ARMY  OR  USMC 

AFLOAT  =  DTRC 

NEW  MARINES  W/ 

NAVY  AFLOAT  =  DTRC 
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There  are  some  severe  shortcomings  in  SHIPDAM.  We  don't  have  a  fire  model  in 
it.  and  we  don't  even  have  a  very  good  fire  model  in  SDM.  We  have  been  working  on 
this  problem,  but  the  number  of  variables  is  fairly  large  which  makes  the  problem 
rather  difficvlt.  WTe  are  approaching  this  problem  more  from  a  historical  viewpoint. 
We  are  going  through  the  JAG  reports  and  the  Navy  Safety  Center  results,  trying  to  get 
a  feel  for  how  much  additional  damage  is  caused  by  fire. 

The  algorithms  for  human  casualties  as  a  result  of  smoke  and  fire  are  different 
than  our  normal  algorithms  for  equipment;  the  equipment  is  fixed.  The  personnel  have 
the  option  of  getting  out  of  the  way  of  a  lot  of  smoke  and  fire.  I  am  not  sure  how 
that's  going  to  work  yet. 

Our  previous  work  concentrated  primarily  on  mission  capability  of  the  ship,  and 
that  if  it  lost  its  mission  capability  and  sunk,  that  was  that.  Now  we  have  included  the 
impact  of  actually  sinking.  For  casualties  it  matters  how  quickly  it  sinks,  it  matters 
what  sort  of  water  it  sinks  in.  and  it  matters  how  bad  the  damage  was. 

The  Navy  planning  procedures  call  for  information  on  when  someone  becomes  an 
inpatient.  This  requires  that  we  modify  our  classification  of  a  casualty.  We  will  need  to 
use  a  step  function.  The  individual  is  either  out  there  working  and  doing  his  job,  or  he 
is  an  inpatient.  We  have  to  adjust  the  algorithms  a  little  and  make  sure  that  people  go 
into  the  medical  facilities  before  they  are  counted. 

One  correction  we  are  working  on  involves  the  location  of  people  in  the  vital  zones. 
I  have  been  putting  as  many  people  as  are  in  that  vital  zone  at  the  centroid  of  the  vital 
zone.  That's  fine  if  there  are  one  or  two  guys  in  there,  but  if  it’s  a  big  zone  and  there 
are  a  lot  of  people  1  have  to  go  back  and  spread  them  out.  I  am  getting  inappropriate 
results  because  of  that. 

There  are  some  other  initiatives  that  are  upcom,'  g  on  SHIPDAM.  I  have  told  you 
about  the  "time  to  repair"  algorithm  we  are  working  on.  It’s  also  been  requested  that 
we  put  in  a  measure  of  structural  damage.  Up  until  now  we  have  just  been  doing 
mission  damage.  We  are  also  going  to  try  to  use  the  SHIPDAM  model  to  prioritize  the 
prepositioning  of  battle  spates  because  it’s  quick  and  easy.  We  are  also  going  to  try  to 
model  system  reliability  and  human  performance.  I  have  never  seen  any  of  the  war 
games  where  reliability  has  even  been  considered,  and  I  am  going  to  try  to  include  a 
column  in  my  vital  component  data  that  gives  a  measure  of  reliability  of  systems. 


227 


Human  performance  seems  very  analogous  to  systems  reliability,  so  we  are  going  to  try 
to  simulate  it  also.  The  current  way  we  model  with  no  reliability  degradation  is 
unrealistic. 

I  would  like  to  make  a  few  final  comments  about  modeling  generally  because  of  my 
experience  with  this.  I  have  seen  in  the  SVM  a  design  tool  that  has  become  terribly 
complex.  It  results  in  terribly  complex  solutions.  The  people  who  make  these  sorts  of 
models  become  advocates  of  their  models.  They  become  really  enamored  with  making 
the  models  perfect,  or  as  near  perfect  as  they  can.  The  models  become  increasingly 
complex.  There  is  a  tendency  to  not  want  to  take  a  chance  of  not  including  something, 
so  you  include  everything. 

Validation  is  almost  impossible  on  these  sorts  of  models  because  you  can  not  do 
experimentation.  You  have  got  to  try  to  bend  historical  data  that  was  not  meant  to 
validate  the  model.  There  is  constant  change  and  growth  in  the  model,  and  ultimately  it 
gets  to  where  it's  too  big.  It’s  so  big  that  the  user  can’t  use  it 

It's  not  necessarily  a  good  thing  to  have  a  model  be  totally  universal.  If  you  are 
going  to  use  it  in  a  small  area,  it  only  needs  to  be  good  in  that  small  area.  The  SVM 
for  a  long  time  became  very  unresponsive.  People  would  ask  questions  and  by  the  time 
we  could  answer,  they  didn’t  care. 

SHIPDAM  allows  them  to  get  a  quick  answer,  and  it  also  serves  as  a  pretty  nice 
preprocessor  for  the  SVM.  If  you  have  a  hard  question  that  might  require  looking  at  15 
or  more  alternatives  to  find  to  one  or  two  you  need,  you  might  consider  using  a  small 
program  like  SHIPDAM.  It  can  do  the  preprocessing  for  you  so  that  your  detailed 
modeling  can  be  concentrated  on  detailed  problems  that  are  appropriate  for  them. 

MR.  BANKS:  Have  you  noticed  something  implicit  in  all  these  presentations, 
virtually  all?  Janus.  TWSEAS.  some  of  the  other  models  assume  that  people  are 
perfect.  Does  that  come  across  to  you?  It  has  to  me.  We  make  assumptions  that  the 
center  of  the  universe  is  the  weapon,  not  the  person  who  has  to  manage  it.  We  model 
that  weapon  very  well;  its  trajectory,  its  fire  rate,  cycling  rate  of  fire,  pounds  per 
square  inch,  ail  of  the  physical  attributes.  But  the  assumption  is  that  people  don't  make 
mistakes. 
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I  was  talking  to  some  of  my  Marine  colleagues  and  I  said,  (this  was  a  couple  of 
months  ago)  if  I  send  ten  squads  out  in  Vietnam,  how  many  squads  are  going  to  know 
where  they  are  after  let’s  say  four  hours,  five  hours?  What  percentage  of  the  squads 
will  report  their  correct  position  back  to  headquarters?  I  have  a  pretty  good  idea  what 
that  is,  and  it’s  far  from  100%.  It’s  nowhere  near  it.  It’s  far  from  90%.  It  varies 
anywhere  from  80%  for  a  good  squad  to  50%.  But  most  of  the  models,  at  least  the  ones 
that  I  have  seen,  assume  the  individual  will  not  make  a  mistake. 
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SHiPDAM  CASUALTIES 
PROCEDURE 


LOCATE  PERSONNEL  AT  GQ 
STATIONS 

ADD  LOCATIONS  IF  NECESSARY 

INCORPORATE  INJURY  ALGORITHMS 

ASSESS  EFFECTS  OF  LARGE 
NUMBER  OF  HITS  &  TRIALS  FOR 
EACH  SHIP  CLASS  &  WEAPON 
COMBINATION 

OUTPUT  IN  TERMS  OF  EXPECTED 
KILLED  &  WOUNDED  AS  A 
FUNCTION  OF  SHIP,  WEAPON, 
NUMBER  OF  HITS 


PERSONNEL  LOCATIONS 


•  SHIP  MANNING  DOCUMENTS 
(GENERAL  QUARTERS) 


ALGORITHMS 


•  SHOCK  (UNDERWATER  EXPLOSIONS) 
FROM  DTRC,  NBDL  WORK 

•  OVER-PRESSURE  (AIR  BLAST) 

FROM  ARMY  LITERATURE 

•  OVER-PRESSURE/BLAST  (INTERNAL 
EXPLOSION)  FROM  SSVP/SVM 
OVER-PRESSURE  TRANSLATIONS 
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SHIPDAM  -  CASUALTIES 

MAJOR  PROBLEMS 


•  FIRE  MODEL 

•  FIRE  &  SMOKE  CASUALTY 
ALGORITHMS 

•  EFFECTS  OF  SINKING 

•  DISTINGUISHING  ’ONSET  OF 
INJURY’  FROM  ’INPATIENT’ 


OTHER  INITIATIVES 


•  INCLUDE  ’TIME  TO  REPAIR’ 

•  ADD  MEASURE  OF  STRUCTURAL 
DAMAGE  (PLATING,  CABLING, 
PIPING) 

•  USE  TO  PRIORITIZE  BATTLE 
DAMAGE  SPARES  ALLOCATIONS 

•  ADD  RELIABILITY  MEASURES 

•  ADD  HUM/  N  PERFORMANCE 
DEGRADATION 
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JOINT  AGENCY  MEETING  ON  COMBAT  SIMULATION  ISSUES 

CONTINUED  SESSION 

Thursday,  December  1, 1988 
Building  381 
Room  1306 


CDR  CONTRERAS:  When  I  talked  to  Dennis  and  he  asked  me  to  talk  to  this 
group,  there  was  a  funny  pause  after  I  hung  up  the  phone  with  him.  I  stopped  to  think 
what  is  it  he  wants  me  to  talk  about?  I  said,  "gee!  What  he  wants  me  to  talk  about  is 
the  Navy's  need  for  computer  modeling,  and  that  is  exactly  what  I  came  here  to  find 
out."  My  program  is  a  very  diverse  program.  I  handle  all  the  62  exploratory 
development  programs  in  the  biomedical  and  CBR  community.  So  I  deal  with  quite  a 
diverse  community.  I  take  the  opportunity  to  come  to  meetings  like  this  to  learn  from 
the  user  and  the  experts  basically  what  they  feel  the  requirements  are.  That  way  I  can 
go  back  with  some  idea  of  what  you  guys  need,  and  try  to  incorporate  that  information 
into  the  prioritization  scheme  that  my  organization  goes  through.  So  what  I  would  like 
to  do  this  morning  (since  I  can  t  tell  you  what  I  was  supposed  to  tell  you).  I  would  like 
to  take  the  opportunity  to  discuss  with  you  the  Navy  R&D  structure,  because  I  can 
pretty  well  assume  that  although  the  majority  of  you  have  worked  for  Navy  RAD  for 
many  years,  you  really  can't  tell  me  what  the  structure  is  all  about,  or  how  it  works. 

it's  very  important  for  you  to  know  something  about  the  structure.  If  you  are 
going  to  work  within  it,  you  need  to  know  how  it  works,  because  otherwise  you  won't  be 
successful  in  doing  what  you  need  tc  do.  The  Navy  R&D  system  is  quite  unique.  It’s 
totally  different  from  any  other  service.  The  reason  I  say  that  is  because  Navy  R&D  is 
composed  of  three  separate  and  distinct  funding  sponsors,  each  with  their  own 
philosophy,  each  with  their  own  way  of  doing  things,  each  with  their  own  aims  and 
£oai3.  Hopeful Iv  they  should  end  uo  "'orkirv  in  the  same  direction,  with  the  same 
objective,  b  j*  there  are  t'uree  separate  organizations. 

The  first  organization  is  the  Office  of  Naval  Research.  It  funds  all  the  6.1  research. 
They  fund  those  basic  research  programs  that  have  a  bunch  of  free  thinkers  developing 
novel  ideas  and  innovations.  The  second  funding  sponsor  is  the  Office  of  Naval 
Technology,  my  organization.  We  fund  all  the  6  2  exploratory  development  research 
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done  in  the  Navy.  Again,  we  have  our  own  way  of  doing  things.  Lastly  is  the  Chief  of 
Naval  Operations  via  OP  98.  and  the  various  OP  codes.  They  fund  ail  the  6.3,  6.4 
advanced  engineering  development  within  the  Navy.  Program  managers  for  the  6.3  and 
6.4  programs  are  at  the  SYSCOMs.  So  it’s  a  very  complex  situation.  The  system  has 
both  positive  aspects  and  some  drawbacks  to  it.  From  my  perspective  I  think  one  of  the 
biggest  positive  aspects  of  this  type  of  system  is  that  every  time  a  technology  transitions 
from  one  funding  sponsor  to  another,  it  is  validated  again  and  reprioritized. 

For  instance,  when  a  particular  technology  begins  its  development  within  the  basic 
research  structure  as  it  matures,  eventually  it  will  transition  to  the  6.2  community, 
which  is  my  community.  When  it  comes  into  my  community  I  look  at  it,  and  the  first 
thing  I  do  is  look  at  the  fleet  requirement  to  determine  if  it  is  still  valid.  Does  the  fleet 
still  have  the  problem,  and  does  that  problem  still  need  to  be  addressed  and  solved?  If 
the  answer  is  yes,  then  I'll  accept  it.  If  it’s  no.  then  why  proceed  with  it?  The  second 
thing  I  do  is  compare  it  with  the  other  projects  within  my  organization.  With  my 
funding  constraints.  I  have  to  prioritize  all  my  programs.  Maybe  it  was  a  low  priority 
at  the  6.1  level,  but  I  find  that  it  is  a  hot  item,  it’s  doing  well,  it’s  a  good  technology  and 
we  need  to  get  it  out  there  quickly.  I  will  prioritize  it  at  a  higher  level  and  try  to 
accelerate  it  out  of  the  6.2  community  into  the  6.3  community.  When  I  transition  things 
into  the  6.3  community.  *hey  in  turn  do  the  same  thing  that  I  did.  They  revalidate  and 
reprioritize  again.  So  a  program  that  starts  at  the  6J.  level  which  has  a  fleet  turnover 
maybe  15  to  20  years  hence,  is  validated  and  reprioritized  as  it  goes  up  the  line.  Because 
in  many  cases  you  might  have  a  problem  today  that  by  the  time  that  technology  gets  out 
to  the  fleet,  it’s  no  longer  a  problem.  Either  the  scenario  changed,  or  something 
happened  that  made  that  particular  problem  20  years  back  non-significant. 

We  feel  it’s  a  good  process  for  getting  the  technologies  out.  because  its  more  mission 
relevant  than  the  other  services.  The  drawback  behind  the  system  is  that  transitions  are 
hard  or  impossible  if  there  is  no  communication  between  the  various  sponsors.  I  sit  in 
what  I  consider  a  very  prime  position  because  I  have  6.1  programs  under  me  and  I  have 
the  6J  community  above  me.  I  sit  in  the  middle. 

One  of  my  main  functions  within  the  biomedical  CBR  community  is  to  keep  looking 
down  at  the  6.1  community  to  see  what  technologies  are  they  are  developing.  Because  as 
those  technologies  develop,  1  need  to  have  programs  out  in  the  future  that  will  be  ready 
to  accept  the  transition  of  the  6.1  program.  If  I  don’t  have  them  in  place,  then  there  is 


no  place  for  the  6.1  technology  to  transition  into.  So  it  takes  a  nice  constant  coordination 
between  the  6.1  people  and  the  6.2  people.  Captain  Tom  Jones  was  (prior  to  his  present 
assignment)  at  ONR  Code  12.  which  is  the  applications  section  of  ONR.  They  are 
responsible  to  make  sure  that  the  6.1  technology  indeed  gets  transitioned  into  the  6.2 
community.  They  are  like  the  link  between  the  two  communities.  We  have  worked 
very,  very  close  with  them.  Their  function  is  to  make  sure  they  know  what’s  going  on  in 
6.2  so  they  can  successfully  transition  6.1  products  into  62. 

That’s  looking  down.  On  the  other  hand.  I  am  looking  up.  I  am  constantly  going  to 
the  SYSCOMs  and  looking  to  see  what  programs  they  have.  How  stable  are  they?  How 
are  they  funded?  Will  those  programs  be  around  when  I  am  ready  to  transition  6.2 
technology  to  6.3?  If  they  are  not  there  now.  I  better  make  sure  that  I  talk  to  the  6.3 
community  so  that  they  POM  monies.  So  that  when  my  technology  is  ready  to 
transition  to  6.3  those  programs  are  available,  or  otherwise  i  am  going  to  have 
technology  that  will  die  on  the  vine,  because  there  is  nowhere  for  me  to  transition  it  to. 
So  it’s  a  constant  struggle.  It  takes  constant  communication  among  the  three  funding 
sponsors  to  get  a  product  from  6.1  all  the  way  to  6.4. 

Prior  to  being  at  the  Office  of  Naval  Technology.  I  was  at  the  Naval  Medical 
Research  and  Development  Command.  I  was  a  p-ogram  manager  for  Fleet  Health  Caro 
Systems,  or  Combat  Casualty  Care.  There  I  handled  6.1  through  6.4  in  a  very  narrow 
field,  but  I  managed  the  full  length.  I  received  money  from  ail  three  sponsors.  That’s  a 
very  unique  situation,  not  very  common  within  the  Navy  where  you  have  one 
organization  that  is  functioning  to  cover  that  type  of  scope,  from  6.1  to  6.4;  one  manager 
doing  it  all. 

In  the  other  communities  you  have  three  separate  managers  (one  for  each  level  of 
funding)  and  they  must  communicate.  I  had  a  real  advantage  of  sitting  there  managing 
a  program  from  6.1  through  6.4.  There  are.  as  you  all  know,  a  variety  of  types  of 
researchers.  There  are  basic  scientist.3  who  says  ’’hey.  leave  me  alone,  let  me  think,  I 
need  my  space.  Let  me  innovate.  Let  me  think.  Don’t  give  me  any  constricted 
direction.  Let  me  use  my  technology.  I  am  not  going  to  worry  about  applying  it.  I  just 
want  to  develop  the  technology."  These  are  free  thinkers,  and  we  need  them.  We  need 
those  tech  base  people.  Very  important*'  Those  are  people  that  handle  future  problems. 
We  need  them  and  we  need  to  support  them  by  keeping  them  well  funded. 
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Then  you  have  the  6.2  scientist.  The  in-betweener  who  is  probably  the  type  of 
researcher  that  says.  "1  know  we  have  a  problem  out  there,  I  know  what  type  of 
technology  is  going  on;  let’s  see  what  I  can  do  about  taking  that  non-directed  technology 
and  developing  a  product.  I  know  that  you  need  something  out  there  in  five  or  six 
years,  so  let  me  work  on  it  and  I’ll  have  something  for  you.” 

Finally,  you  have  your  advance  development  people,  the  scientist  who  says,  "I  have 
got  a  problem,  and  I  needed  to  have  a  solution  yesterday.”  They  are  very  impatient. 
They  want  to  get  things  out  there  quickly.  They  don’t  have  the  mentality  of  the  basic 
researcher.  They  are  very  anxious  to  develop  a  product.  They  get  a  thrill  out  of  getting 
that  product  or  technology  out  to  the  fleet. 

The  problem  with  the  system  is  communications.  Communications  between 
managers,  and  communications  between  managers  and  scientists.  Communications  at  the 
working  level  appear  to  be  pretty  good.  Scientists  seem  to  communicate  with  each  other 
very  well  with  no  problem.  It’s  the  managers  at  our  levels  who  have  worked  for  years 
in  a  very,  very  stratified  environment  that  seem  to  have  difficulty  communicating. 

With  this  background,  I  would  like  to  impart  to  you  the  four  basic  criteria  that  I 
use  in  evaluating  programs  that  will  in  my  opinion  become  successful,  will  be  funded, 
and  will  proceed  on  to  an  end  product.  My  understanding  from  the  meetings  of 
yesterday  and  today  is  that  you  are  trying  to  bring  together  the  various  individuals 
working  on  human  performance  modeling  and  create  a  cohesive  program  in  an  effort  to 
develop  better  models  for  use  within  the  Navy.  Thu  sounds  like  a  new  initiative,  and  I 
assume  you  are  going  to  need  new  funding  for  it. 

Well,  to  survive  in  today’s  environment  of  funding  cuts  you  need  to  meet  four 
criteria.  The  four  criteria  that  I  use.  and  I  think  most  of  the  managers  in  my  area  use 
are: 


Number  one,  because  of  the  money  constraints  there  has  to  be  a  documented 
need  or  requirement  in  the  system  before  we  initiate  a  new  program. 
Furthermore,  once  you  have  identified  that  requirement,  you  should  take  the 
time  to  understand  exactly  what  the  problem  is  that  need3  to  be  addressed. 
Too  many  times  you  take  a  requirement,  (assuming  you  know  what  the  problem 
is)  go  into  the  laboratory,  work  on  the  problem,  and  then  present  it  to  the  user 
and  he  laughs  in  your  face.  That  has  happened  too  many  times  in  the  past. 
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It’s  not  the  case  any  more.  I  honestly  think  we  have  made  a  dramatic  change 
in  that  area.  We  need  to  spend  more  time  with  the  originator  of  the 
requirement,  and  sit  down  and  talk  to  him  and  say  "what  is  the  problem? 
What  do  you  perceive  to  be  the  problem?" 

Second,  develop  a  well  laid  out  plan  with  goals  and  an  approach  that  reflects 
that  you  understand  what  the  problem  is.  Within  that  plan,  have  milestones 
that  indicate  that  you  will,  as  you  proceed  in  addressing  this  particular 
problem,  sit  down  at  various  times  with  the  user  so  that  he  can  independently 
assess  your  progress. 

Three,  as  you  develop  your  ideas  regarding  a  research  area,  it  is  important  to 
attend  meetings  such  as  this.  These  meetings  provide  good  access  to 
information  you  need  to  understand  what  the  problem  is,  and  to  make  you 
aware  of  what  is  available  already.  That’s  very  important  in  developing  an 
approach.  You  have  got  to  show  that  you  have  made  a  very  strong  effort  to 
determine  what  is  available  today,  what  industry  is  doing,  what  academia  is 
doing,  how  are  they  solving  these  problems?  This  meeting  has  done  that  very 
well.  You  have  brought  in  people  that  are  all  doing  modeling  work,  and  you 
are  comparing  notes.  The  fact  that  someone  else  is  working  on  the  same 
problem  you  are  should  not  be  a  deterrent.  A  lot  of  people  are  afraid  to 
include  this  type  of  information  in  their  proposals  or  their  game  plan,  simply 
because  they  are  afraid  that  it  will  affect  their  chances  of  being  funded.  As 
long  as  the  projects  are  not  a  complete  duplication  of  effort,  and  yours 
addresses  some  unique  Navy  needs,  there  isn’t  going  to  be  a  problem.  In  fact, 
if  someone  else  has  a  parallel  effort  going  on  and  you  are  communicating,  it 
will  enhance  your  project  and  improve  your  changes  of  funding.  I  see 
proposals  constantly  wnere  80%  of  the  cost  of  die  program  is  the  acquisition  of 
equipment;  equipment  that  could  be  borrowed  from  somebody  else  working  in 
the  field.  In  this  regard,  parallel  research  efforts  could  be  very  cost  effective. 
It’s  nice  to  build  up  your  laboratories  with  new  equipment,  but  nowadays  the 
money  isn’t  there.  So  what  you  need  to  do  is  start  looking  around  as  you  are 
doing  here  today  and  find  opportunities  to  share  resources.  When  we  can  see 
that  that  type  of  effort  is  taking  place,  you  have  got  one  up  on  the  program 
that  didn’t  do  that. 
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Lastly,  understand  the  R&D  system.  Take  the  effort  to  understand  how  the 
R&D  system  works.  Know  who  the  program  managers  are.  know  who  the 
champions  for  a  particular  project  are  so  that  you  can  continuously  supply  him 
with  the  information  or  the  shield  that  he  needs  to  protect  that  program  once 
it  gets  under  way.  A  lot  of  times  we  get  a  request  for  information  from  a 
department  or  division  head,  which  trickled  down  from  NMRDC,  and  the  first 
thing  that  comes  to  mind  is  that  we  have  another  paper  drill.  Don’t  take  these 
requests  lightly.  When  I  was  a  bench  level  researcher,  if  I  had  known  what  I 
know  now,  I  would  have  taken  the  request  for  information  a  lot  more 
seriously.  The  information  you  provide  is  the  shield  that  the  program  manager 
needs  to  defend  your  program.  If  you  do  a  bad  job  in  describing  to  him  what 
you  are  doing,  how  can  he  defend  the  program?  In  most  cases  we  think  that 
the  more  information  we  give  to  the  program  manager,  the  more  ammunition 
he  has  to  cut  my  program.  It’s  net  the  ca ae.  The  more  information  you  give 
him.  the  better  able  he  is  to  evaluate  your  program  and  mike  a  wise  decision. 
In  most  cases  if  he  understands  what  you  are  doing,  he  is  going  to  defend  it; 
not  use  that  information  against  you.  So  take  the  time  to  accurately  report 
accomplishments  and  progress.  Write  in  layman  style  a  very  thorough  report 
of  the  accomplishments,  because  your  program  manager  is  going  to  take  that 
information,  and  use  it  to  brief  people  who  know  less  about  the  program  than 
he  does.  He  has  got  to  be  able  to  tell  those  people  what  you  are  doing  in 
layman  type  language.  Don’t  make  your  accomplishments  so  complicated,  so 
technical,  that  only  your  peers  can  read  it  or  understand  it.  They  can  pick  up 
that  information  from  your  publications.  What  we  need  is  information  written 
like  a  newspaper  article;  not  a  scientific  article.  The  people  I  will  try  to 
explain  the  program  to,  defend  the  program  to,  that’s  what  they  want  to  hear. 
That’s  what  they  want  to  understand.  If  they  want  more  technical 
information,  they  will  ask  for  it. 


So  with  that  as  a  background,  I  have  a  few  figures  to  help  explain  the  inner 
workings  of  each  of  the  funding  sponsors.  I  am  going  to  specifically  speak  about  ONT 
because  that’s  the  organization  I  understand  thoroughly.  But  take  into  account  that  the 
other  organizations  have  almost  identical  goals  and  function  basically  the  same.  Each  of 
these  sponsors  have  responsibilities.  Most  of  them  are  similar  to  those  shown  in  the  first 
figure. 
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These  are  specifically  for  ONT.  but  we  develop  some  kind  of  investment  strategy 
for  each  of  the  research  areas.  We  develop  an  investment  strategy,  which  we  call  the 
"mission  area  strategy"  with  inputs  from  OSD,  CNO.  the  Marine  Corps,  the  SYSCOMs, 
and  various  other  organizations.  We  address  their  needs  when  we  develop  the  mission 
area  strategy. 

The  responses  listed  in  the  figure  are  the  ones  I  have  as  a  program  manager.  I 
conduct  and  plan  programming,  budget,  etc.,  for  my  area.  We  provide  annual  reviews 
of  our  programs  every  fall.  We  invited  the  world  to  come  and  look  at  our  block  plans. 
I'll  explain  what  a  block  plan  is  very  shortly.  Some  block  plans  are  classified,  so  only 
those  people  with  appropriate  clearances  can  attend,  but  all  services  and  other  branches 
of  government  are  invited.  The  second  to  last  item  on  the  figure  is  very  important.  We 
are  the  organization  within  the  62  community  that  represent  and  defend  6.2  programs. 
If  we  don’t  do  a  good  job  of  representing  our  programs  not  only  in  Congress,  but  within 
our  own  organization,  we  will  lose  money.  We  are  constantly  competing  with  other 
TAMs  (Technical  Area  Managers)  for  available  funds.  If  a  program  falls  by  the 
wayside,  we  all  compete  for  the  funds.  Lastly,  we  interface  with  other  organizations. 
Not  only  other  Navy  orga  'zations,  but  within  the  CBR  community  we  also  interact  with 
the  Army,  the  lead  agency  for  CBR. 

SYSCOM.  As  I  indicated,  we  work  in  partnership  with  other  organizations,  and 
they  also  have  responsibilities.  Responsibilities  not  only  to  us.  but  to  their  funding 
sponsors.  The  next  figure  shows  the  SYSCOM  responsibilities.  They  serve  as  principal 
advisers  to  our  programs.  They  critique  our  programs  and  make  sure  that  our 
investment  strategy  is  heading  in  the  right  direction.  The  SYSCOMs  represent  the  user 
and  advise  us  constantly.  The  SYXOMs  develop  and  provide  documentation  regarding 
priorities,  requirements  and  system  needs.  We  need  to  know  what  problems  they  are 
having  so  that  we  can  address  them  properly.  The  SYSCOMs  participate  in  ONT 
planning  and  reviews.  As  I  said,  when  we  have  reviews,  and  as  we  develop  that  block 
plan,  we  work  with  them  to  make  sure  that  we  don’t  take  shortcuts  that  they  are  not 
going  to  accept.  In  essence,  what  they  do  is  provide  independent  technical  assessments 
of  our  programs.  That  is  very  important.  They  do  the  same  thing  for  the  other 
sponsors  too.  They  also  work  in  partnership  with  the  research  labs  to  make  sure  the 
labs  are  the  executing  our  program  properly. 
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m  RESPONSIBILITIES 


DEVELOP  INVESTMENT  &  MISSION  AREA  STRATEGIES: 
OSD,  SECNAV,  GIO,  CMC  IlfUT 

CONDUCT  PLANNING,  PROGRAMING,  BUDGETING 

PROVIDE  GUIDANCE  TO  CLAIMANT  &  PERFOFHER 

PROVIDE  REVIEW  AND  APPROVAL  OF  PRO GWS 

ALLOCATE  FUNDING  &  FISCAL  ACCOUNTABILITY 

PROVIDE  OVERSIGHT  OF  PROGRAM  EXECUTION 

REPRESENT  &  DEFEND  6.2  PROGRAMS 

INTERFACE  WITH  OTHER  NAW  ORGANIZATIONS 


Serve  as  Principal  Advisers  to  ONT  in 
Development  of  Investment  are!  Mission 
Area  Strategies 

Develop  and  Provide  Documented, 
Prioritized  Systems  Technology  Needs 

Participate  in  ONT  Planning  &  Review 

Provide  Independent  Technical  Assessment 

Work  in  Partnership  with  ONT  &  Labs  to 
Facilitate  Technology  Transitions 


Navy  Laboratories.  The  Navy  Iab3  and  R&D  centers  have  their  own 
responsibilities.  The  R&D  centers  are  the  people  who  plan  and  execute  the  effective 
block  plan.  A  block  plan  is  a  strategy  that  is  devised  in  response  to  the  mission  area 
strategy.  We  split  the  mission  area  strategy  among  the  labs,  and  they  decide  based  upon 
their  resources  and  expertise  which  sections  they  want  to  be  responsible  for.  The  mission 
area  strategy  goes  out  about  March.  From  March  until  October  the  labs  develop  a  block 
plan  in  concert  with  the  SYSCOMs.  I  have  five  block  plans  out  of  approximately  200  at 
ONT.  I  review  those  block  plans  and  make  sure  that  it  is  indeed  in  accordance  to  the 
guidance  that  we  give  them. 

Prior  to  block  plan  acceptance  and  approval  by  Phil  Sullivan,  they  are  submitted  to 
the  SYSCOMs  for  comment.  They'll  come  back  to  us  with  comments  and  before  Phil 
Sullivan  approves  that  block  we  have  to  show  to  him  that  we  have  addressed  the 
SYSCOM  comments.  Once  that  block  plan  is  approved,  then  we  have  the  fall  reviews. 
So  it’s  always  checks  and  balances  with  the  system  to  make  sure  that  indeed  we  are 
doing  the  right  thing.  But  it’s  the  Navy  laboratories  and  in  this  case  NMRDC,  who  has 
the  medical  laboratories  under  its  jurisdiction,  that  develops  the  block  plan.  They  also 
coordinate  with  the  SYSCOMs  and  us  to  promote  technology  transition.  I  have  a  block 
manager  for  each  of  my  blocks,  and  his  responsibility  and  the  responsibility  of  his 
people  is  to  keep  pushing  transition. 

The  block  managers  are  responsible  for  keeping  the  SYSCOM  commanders 
constantly  aware  of  what  we  are  doing  at  the  62  level,  because  these  are  the  people  that 
need  to  prepare  their  programs  to  accept  our  technologies  when  they  are  ready  to 
transition. 

Marine  Corps  organization  and  responsibilities  are  somewhat  different.  The  Navy 
medical  community  addresses  all  of  the  Marine  Corps  medical  problems.  We  are  their 
medical  system.  So  if  they  have  problems  in  the  medical  area  we  are  responsible  for 
addressing  them.  We  need  to  know  what  their  problems  are  so  that  we  can  incorporate 
those  problems  into  our  mission  area  strategy.  So  we  constantly  work  with  the  Marine 
Corps.  The  Marine  Corps,  like  the  SYSCOMs,  is  responsible  for  developing  and 
providing  us  their  technology  needs.  To  do  this  they  work  in  partnership  with  Navy  labs 
to  make  sure  that  we  are  addressing  their  concerns.  Mission  area  strategy  objectives  are 
a  list  of  things  that  the  mission  area  strategy  needs  to  accomplish.  Each  one  of  the 
TAMs  is  responsible  for  developing  their  mission  area  section  of  the  strategy.  Just 
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NAVY  LABORATORY  AND  R&D 

CENTER  RESPONSIBILITIES 
•  Ran  and  Exeats  Effective  Elock  Program 


•  Work  in  Cooperation  with  SYSCOMa  and  ONT 
to  Promote  Technology  Transition 

*  Mamtaai  Communication  with  SYSCQM 
Commanders  on  6.2  Btocks/Projects 
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BLOCK  PROGRAMMING 


*  Streamline  6.2  Program  Management 
Structure  &  improve  Coordination 

*  Minimize  Resources  &  Time  Consumed  by 
Program  Reporting,  Review  &  Approval 
Process 

■  improve  Program  Responsiveness  and 
Mininize  HQ  Involvement  h  Execution 

*  Reduce  Proyam  Framentatscn,  Improve 
Productivity,  Relevance,  Quality  and 
Allocation  of  Resources 


BLOCK  PROGRAMMING 
Objectives  (Cent) 

Promote  Management  Efficiency  and 
Flexibility 

Increase  CoCeeCve  Effectiveness  by 
Promoting  Cocperabcr.  &  Cocndaticn 
Among  Navy  Laboratories 


Clarify  and  SmpSy  Line  of  Rscal  end 
Performance  Aaxssiatiily 


Set  Priories 

Defee  Block  Program  Ojectiyes 
Provide  Vehicle  fcr  Desonbtej  6.2 


recently  we  nave  gone  to  a  biannual  mission  area  strategy  review  instead  of  an  annual 
one.  Within  the  mission  area  we  set  priorities  and  provide  investment  strategies.  It’s  a 
five-year  program  that  tells  you  what  we  are  going  to  do  at  ONT  in  the  6.2  funding  area 
for  the  next  five  years. 

Recently  ONT  went  to  the  execution  of  its  programs  via  block  programs.  There  are 
a  variety  of  reasons  why  we  went  to  block  programming.  As  the  money  becomes  more 
scarce,  we  have  got  to  be  more  efficient  in  doing  what  we  do.  So  we  consolidated  areas 
»nto  block  plans  to  minimize  resources  and  streamline  the  system.  The  system  also 
tends  to  promote  management  efficiency  and  flexibility.  The  system  appears  to  be 
working.  We  are  much  more  efficient  than  we  were  before.  You  are  forced  by  budget 
cuts  to  become  more  efficient.  If  you  don’t,  you  don’t  survive. 

I  have  described  the  inner  workings  of  ONT.  Although  what  I  told  you  is  specific  to 
ONT.  the  other  funding  sponsors  go  through  about  basically  the  same  routine.  Different 
schedules,  different  times,  but  basically,  they  do  the  same  thing. 

My  boss,  whose  office  is  down  the  hall,  is  really  not  my  boss.  The  person  that  I 
work  for  is  the  Marine  Corps  grunt  out  in  the  field,  and  the  sailor  out  on  the  ship. 
Those  are  the  people  that  I  work  for.  Those  are  the  people  that  I  need  to  know  what 
their  needs  are.  Many  times  we  managers  forget  that  We  get  all  caught  up  in  power 
struggles  and  everything  and  we  forget  who  we  work  for.  And  that’s  when  the  system 
starts  hurting. 

I  have  some  key  issues  that  I  would  like  to  bring  up  because  they  are  bothering  me. 
When  we  get  requirements  from  the  SYSCOMs  often  times  they  themselves  don’t  have 
a  clear  idea  as  to  what  they  want  or  what  the  problem  is,  so  it’s  very  hard  for  the 
research  community  to  address  their  problems.  I  think  there  should  be  a  better  system 
for  having  the  fleet  submit  their  concerns  to  the  SYSCOMs.  Something  has  to  be  done. 

We  have  a  new  program  called  ATD  'Advanced  Technology  Development). 
Actually,  it’s  not  new  in  the  Navy,  but  it  might  be  new  throughout  the  other  services. 
The  program  is  deigned  to  help  with  the  transition  of  projects  from  6.2  to  63  funding. 
It’s  bridge  money  from  6 2  to  6.3-A.  I  mention  this  program  because  it’s  a  very  good 
system  to  get  a  quick  transition  or  an  accelerated  transition  from  62  to  6.3-A.  If  you 
have  a  high  priority  6.2  program  that  you  think  is  ready  to  transition  into  63  you  might 
try  the  ATD  program.  The  money  is  there,  but  it's  highly  competitive.  Last  year  I 
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MARINE  CORPS  RESPONSIBIUTIE  S 


Advise  ONT  h  Development  of  6.2  Program 
Investment  Strategy  &  Amphibious  Warfare 
Mission  Area  Strategy 

■  Develop  and  Provide  to  ONT  Documented 
Marne  Corps  Needs  and  Priorities 

*  With  Participation  from  Navy  Labs/R&D 
Centers  Develop,  Manage  &  Esacute  MARGOR 
Related  Programs 


EXPLORATORY  DEVELOPMENT 

KEY  ISSUES 

•  Fleet  input  to  SYSCOM  -  SYSCOM  to  ONT 

■  Transition  of  8.2  Mature  Technology  Into 
6.3  SYSCOM  Progaros 

'  Advanced  Technology  Development  (AID) 
Programs 

■  Navy  Lafcoratery/Ft&D  Centers  Interaction 
With  the  Fleet 


•  Block  Plsn  DisStaition 


think  there  were  something  like  54  ATDs  introduced  and  only  five  were  accepted  and 
funded.  Fortunately,  for  the  first  time  the  medical  community  had  one  of  the  five.  In 
the  past  I  would  have  said  we  have  no  chance  in  this  system,  though  we  do  now.  It*s 
changing,  and  people  who  are  making  the  selections  are  looking  at  medical  much  more 
closely.  The  medical  ATD  that  was  funded  for  FY90  start  was  funded  at  the  $33.8 
million  level.  That’s  a  small  ATD,  most  are  much  larger.  The  paperwork  to  submit  an 
ATD  isn't  all  that  hard.  Check  with  your  program  managers.  They  will  give  you 
information  on  how  to  use  the  ATD  to  your  advantage. 

I  was  very  encouraged  to  hear  Captain  Cheney’s  introductory  talk  regarding  what 
was  going  on  at  NHRC.  Just  about  every  word  he  said  was  interaction  with  the  fleet. 
He  indicated  that  he  had  people  out  in  the  Persian  Gulf,  and  he  had  people  with  the 
Marines.  That  is  great!  For  too  many  years  we  have  conducted  research  without  really 
talking  to  the  users.  We  are  doing  it  now,  and  I  think  the  biomedical  community  is 
becoming  more  responsive  to  fleet  and  Marine  Corps  needs. 

I  am  the  only  medical  person  at  ONT.  All  my  counterparts  are  line  officers,  and  I 
just  was  getting  tired  of  listening  to  them  bad  mouth  the  biomedicai  community  because 
we  were  not  responsive  to  their  needs.  I  don't  hear  that  any  more  because  of  the 
success  that  we  are  having  in  the  biomedical  community,  and  it’s  you  people  who  are 
doing  it.  Accomplishments  are  being  achieved  and  programs  are  being  transitioned. 
Every  week  we  compete  within  ONT  to  submit  an  accomplishment  to  ASN.  In  the  last 
three  months  we  probably  have  had  four  from  the  biomedical  community  accepted  and 
sent  to  the  ASN.  We  are  very  competitive  now  thanks  to  you  people.  The  reason  for 
our  success  is  interaction  with  fleet.  We  are  becoming  much  more  mission  relevant  in 
what  we  are  doing.  In  the  past  we  were  not. 

I  would  like  to  address  one  last  issue  before  I  quit.  There  is  a  DOD  organization 
called  DMSSC  (Defense  Medical  Systems  Support  Center).  It’s  the  old  TRIMIS 
organization.  They  have  changed  the  name  to  hide  their  past  sins.  It’s  the  tri-service 
medical  information  systems  organization.  They  initially  started  out  as  being  the  DOD 
coordinators  of  computerized  medical  information  systems  so  that  as  each  of  the  services 
develop  their  own  medical  information  systems,  they  could  interact  and  communicate 
with  each  other.  They  were  responsible  for  ail  medical  information  systems  that  the 
service  developed.  When  they  changed  their  name,  their  charter  expanded.  They  are 
now  looking  at  those  medical  computer  systems  that  are  going  cut  into  the  operational 
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theaters.  That  becomes  part  of  their  realm  also.  They  have  extended  beyond  the 
Continental  United  States. 


When  we  started  working  on  the  Navy’s  medical  information  systems  and  computer 
assisted  medical  diagnostic  systems,  we  ran  head  on  into  that  organization.  I  don’t  know 
right  now  what  their  specific  interest  or  responsibility  is  in  modeling  systems,  but  if  you 
have  modeling  systems  that  you  envision  being  operated  within  an  operational  theater, 
you  have  got  to  be  aware  of  that  organization.  They  are  not  an  R&D  organization,  but 
they  are  implemented  of  the  program*;.  So  if  you  are  not  aware  of  this  organization, 
and  you  come  up  with  a  product  and  are  planning  on  implementing  it  into  the  system 
you  might  have  a  problem.  To  avoid  a  problem  I  suggest  you  communicate  with  DMSSC 
early  on  in  your  development  cycle.  Now,  I  am  not  sure  exactly  what  their 
responsibility  is  with  modeling  systems,  but  1  would  check  with  somebody  in  their 
organization.  They  are  located  in  Alexandria.  Virginia. 


QUESTION  FROM  THE  AUDIENCE;  What’s  ONT  doing  in  the  computer 
simulation  area? 

CDR  CONTRERAS:  Well,  I  know  that  ONT  is  one  of  the  sponsors  of  the  Naval 
War  College  war  games.  We  sponsor  those  programs.  There  is  another  office  besides 
myself,  another  TAM  (Stan  Collyer)  who  is  in  training.  I  talked  to  Stan  specifically 
before  I  can  out  here  in  case  I  got  that  specific  question.  Stan  is  not  doing  anything  in 
that  modeling  area  fot  human  performance  right  now.  I  am  sponsoring  the  CBR  work 
at  the  Naval  Surface  Warfare  Center  that  you  saw  presented  yesterday.  I  also  sponsor 
the  work  presented  yesterday  by  NMRDC  and  NHRC.  So,  just  about  everything  the 
Navy  is  doing  in  human  performance  modeling  systems  you  saw  yesterday. 
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DOM  EXPLORATORY  DEVELOPMENT  PROGRAMS 

I.  PROGRAM  OBJECTIVES 

A.  Maintain  Navy,  technology  superiority  &  provide  capability 

to  counter  neu  threats. 

B.  Provide  technology  opportunities  to: 

1.  Preserve  strategic  Naval  initiative  &  flexibility 

2.  Improve  effectiveness  of  U.S.  deterrent  posture 

3.  Present  significant  threats  to  U.S.  adversaries 

4.  Reduce  cost  of  acquisition  &  operations  6  maximize 
system  cost-effectiveness 

II.  RESPONSIBILITIES 

A.  Office  of  Naval  Technology  Responsibilities  are  to: 

1.  Develop  Investment  &  Mission  Area  Strategies  in 
consonance  with  guidance  by  OSD/  5ECKAV/  CNO  and  CMC. 

2.  Conduct  6.2  Planning/  Programming/  and  Budgeting 

3.  Provide  guidance  to  Claimants  and  performers 

4.  Provide  review  and  approval  of  program  plans 

5.  Allocate  funding  and  ensure  fiscal  accountability 

6.  Provide  oversight  of  6.2  program  execution 

7.  Represent  and  defend  6.2  programs  to  higher  authority 

8.  Interface  with  the  SYSCOMs:  OPHAV;  Headquarters/  Marine 
Corps;  and  Ravy  Secretariat 

B.  Davy  Systems  Commands  <SYSC0Hsv  Responsibilities  are  to: 

1.  Serve  as  principal  advisors  to  ONT  in  development  of 
overall  DOM  Exploratory  Development  Program  Investment 
Strategy  and  Mission  Area  Strategy 

2.  Develop  and  provide  to  OMT  documented/  prioritized 
system  technology  needs 

3.  Par  ticipate  in  block  plan  planning  acd  review  process 

4.  Provide  independent  technical  assessments  of  value  of 
6.2  program  product  for  future  SYSCOM  development 

5.  Work  in  partnership  with  ONT  and  Navy  Laborator i es/R&D 
Centers  to  facilitate  technology  transition  to  systems 
programs 

C.  Navy  Laboratories  and  R&D  Centers  responsibilities  are  to: 

1.  Plan  and  execute  effective  block  programs 

2.  Work  in  cooperation  with  SYSCOMs  and  ONT  to  promote 
technology  transition  of  mature  6.2  projects 

3.  Maintain  communication  with  SYSCOM  Commanders  regarding 
exploratory  development  Blocks/Projects 

D.  Marine  Corps  Responsibilities  are  to: 

1.  Advise  ONT  in  development  of  overall  DON  Exploratory 
Development  Program  Investment  Strategy  6  Amphibious 
Warfare  Mission  Area  Strategy 

2.  Develop  and  provide  to  ONT  documented  Marine  Corps 
needs  and  priorities  applicable  to  6.2  program 

3.  With  participation  from  Navy  Laborator ies/R&D  Centers/ 
develop/  manage  and  execute  MARCOR  related  6.2  programs 


254 


in.  MISSION  AREA  STRATEGIES 

Mission  Ares  Strategies  establish  the  DOM  6.2  progras 
objectives  for  each  Mission  area  in  terse  of  the 
operational  impact  of  the  planned  technology  program  on 
the  war fighting  capabilities  of  the  Mavy  and  Marine 
Corps  . 

A.  MISSION  AREA  STRATEGIES  SHALL: 

1.  Provide  program  goals  and  guidance 

2.  Define  technology  thrusts  required  to  achieve  mission 

3.  Provide  investment  strategies 

4.  Set  priorities 

5.  Define  block  program  objectives 

6.  Provide  vehicle  for  describing  the  program 

B.  MISSION  AREA  NEEDS 

1.  Maritime  Strategy  Technology  Area  Concerns 

2.  Threat  Drivers 

3.  System  Deficiencies 

4.  Programmatic  Drivers:  high-level  guidance  which  drive 
priorities  and  schedules 

IV.  BLOCK  PROGRAMMING 

A.  Ojectivea  of  Block  Programming 

1.  Streamline  6.2  program  management  structure  h>  simplify 
&  improve  coordination  between  headquarter  &  performer 

2.  Minimize  resources  and  tine  consumed  by  program 
reporting,  review,  and  approval  processes 

3.  Improve  progras  responsiveness  by  instituting 
managesent-by-ob jectives  policy  and  minimizing  head¬ 
quarter  involvement  in  execution  management 

4.  Reduce  program  fragmentation,  improving  productivity, 
relevant,  quality,  and  allocation  of  resources 

5.  Promote  management  efficiency  and  flexibility 

6.  Increase  collective  effectiveness  by  promoting 
cooperation  and  coordination  among  Navy  labs 

7.  Clarify  and  simplify  line  of  fiscal  and  perfornanee 
accountabi lity 

B.  Block  Plan  Distributed  to  SYSCOMs  for  review  prior  to 
final  approval  by  ONT 

C.  SYSCQH  Comments  are  addressed  prior  to  submittal  for 
approval 

D.  After  final  approval  is  given.  Block  Flan  is  review  again 
at  Fall  Review 

V.  TRANSITIONS 

A.  Coordination  and  cooperation  amoung  SYSCOMs,  Navy 
Laborator i es/R&D  Centers  and  ONT 

B.  Advance  Technology  Development  Program  (AID) 

VI.  FLEET  INPUT  TO  SYSCOMS 

A.  Improve  process  for  submitting  operational  requirements 
and  nevids  to  SYSCOMs  for  incorporation  into  Mission  and 
Strategies  and  address  by  Block  Plans 
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WORKING  GROUP  TASKING  WITH  LCDR  DENNIS  KELLEHER 


LCDR  KEJ 1  F.HRR:  I  can  read  lips  as  well  as  anybody  else,  and  reading  lips  says 
that  we  have  to  deal  with  the  modeling  of  human  performance  as  a  new  initiative  which 
places  some  constraints  on  development,  but  we  can  handle  that.  I  don't  think  we  have 
a  problem  identifying  who  our  sponsors  are  going  to  be.  The  Marine  Corps  has  just 
established  a  new  war  gaming  center.  That  new  war  gaming  center  is  just  getting  off 
the  ground  and  so  maybe  we  need  to  go  talk  to  them. 

I  was  kind  of  interested  yesterday  to  hear  about  the  limit  to  which  the  Naval  War 
Gaming  Center  at  Newport  cares  about  having  realism  imported  into  their  games. 
Maybe  we  could  help  educate  them  a  little  bit  better  as  to  the  degree  to  which  some 
more  realism  within  their  models  could  be  effectively  used. 

So  we  need  to  sit  down  with  CDR  Contreras  and  Captain  Jones  and  identify  specific 
lists,  if  you  will,  of  who  our  sponsors  are  going  to  be.  who  our  identified  requirements 
and  customers  are  going  to  be  within  the  SYSCOMs. 

This  meeting  was  actually  funded  by  NHRC  (with  Med  R&D  Command's  blessing) 
as  a  new  research  initiative.  We  felt  so  strongly  about  beginning  this  initiative  that  we 
funded  it  ourselves.  Individual  principal  investigators  felt  that  this  was  going  to  be  a 
promising  technology  that  could  help  focus  our  individual  research  efforts  so  we 
convinced  Captain  Chaney  to  support  this  initial  effort.  From  here  on  out.  however,  the 
technology  must  stand  on  its  own  merits. 

The  word  we  have  from  Captain  Jones  is  that  this  technology  will  be  something 
that  will  be  encouraged  of  all  principal  investigators  within  Medical  R&D  Command. 
Computer  modeling  should  not  be  the  sole  impetus  for  their  research  efforts,  but  it  can 
serve  as  a  focus  for  requirements,  prioritizing  efforts,  and  packaging  product  to  the 
user.  So  what  wo  want  to  do  is  be  able  to  provide  to  CDR  Contreras  and  Captain  Jones, 
(who  are  our  funding  sponsors)  the  guidelines  for  making  certain  that  these  things  are 
incorporated  into  future  research  efforts. 

CDR  CONTRERAS:  Remember  that  this  type  of  program  isn’t  limited  to  medical. 
The  weapons  centers  have  just  as  big  a  responsibility  and  they  need  the  information  just 
as  badly  as  we  do,  so  don't  forget  them  as  a  possible  funding  sponsor  for  some  of  these 
programs. 
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LCDR  KELLEHER  (NHRC):  I  think  from  the  discussion  of  the  AURA  model  we 
saw  that  there  was  a  methodology,  for  accepting  basically  any  kind  of  input  data.  In 
fact,  as  was  pointed  out  by  Dr.  Kolpcic.  the  AURA  methodology  relies  upon  getting  the 
actual  data  from  the  end  user  and  from  the  laboratory  researcher  as  it’s  produced  by 
them.  That  leads  also  to  the  question  of  how  do  we  exploit  the  data  bases  that  do  exist 
to  find  out  whether  there  are  areas  that  need  further  development?  Have  we  fully 
exploited  the  data  bases  as  they  exist  new?  Have  we  incorporated  the  available  data  into 
models?  Models  such  as  AURA  that  accept  a  broad  spectrum  of  inputs  need  to  list  or 
indicate  the  types  of  data  they  are  looking  to  incorporate.  Are  there  areas  that  are 
specifically  lacking  that  we  need  to  be  working  on? 


DR.  GUNDERSON  (NHRC);  I  was  glad  to  hear  CDR  Contreras  say  there  may  be  a 
possibility  of  working  with  other  groups  (non-medical  groups),  to  perhaps  realize  some 
of  the  goals  that  we  have  been  discussing  here.  But  I  would  like  to  say  that  *t  NHRC 
the  impetus  for  us  is  to  have  a  means  to  represent  combinations  cf  physiological  and 
psychological  variables  tnat  produce  degradation  of  performance.  So  essentially  we 
would  tend  to  concentrate  on  medical  aspects;  that  is,  we  have  the  expertise  to  look  at 
possible  measurement  of  physiological  degradation,  psychological  degradation,  and  that’s 
what  we  would  focus  on.  and  that's  what  we  need  the  model  for.  In  this  case,  we  are 
the  end  use-,  and  need  the  model  as  a  tool  of  our  trade.  We  may  be  able  to  use  some 
other  models  and  plug  in  our  variables.  Our  principal  concern  is  how  do  we  utilize  this 
methodology  in  the  research  process. 

Secondly,  I  think  to  be  responsible  advisers  to  the  various  commanders  who  want 
answers  to  questions  we  have  to  have  means  to  rapidly  assess  the  problem  and  determine 
if  we  have  the  answers  to  their  questions,  and  here  I  think  modeling  may  play  a  role  in 
the  sense  of  helping  us  project  results  which  we  don’t  have  yet.  We  can  see  and  we  have 
seen,  that  these  systems  can  be  designed  to  integrate  the  weapons  systems,  the  personnel 
data,  and  the  medical  data.  We  believe  this  may  be  quite  a  useful  tool,  and  that’s  the 
way  we  look  at  it. 

MR.  PUGH  (NHRC);  Just  to  expand  upon  that,  I  think  what  we  have  done  at 
Naval  Health  Research  Center  historically  has  been  in  the  context  of  epidemiological 
analyses.  Answering  questions  and  coming  up  with  tests  of  a  hypothesis.  I  think  what 
modeling  does  is  come  up  with  answers  to  user’s  questions  in  an  interactive  fashion.  As 
I  see  it  we  are  continuing  our  role  of  coming  up  with  answers  to  medical  questions,  but 
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not  necessarily  in  the  traditional  manner.  Modeling  provides  a  method  for  real  time 
handling  of  spontaneous  user  questions  in  an  interactive  fashion.  1  think  that’s  one  step 
beyond  where  we  have  been  traditionally. 

DR.  KOLPCIC  (ABRL):  I  think  it’s  going  to  be  pretty  important  that  you 
differentiate  between  the  models  that  would  be  developed  in  a  particular  community 
like  the  medical  community,  and  the  large  scale  model,  the  combat  simulation  that  is 
going  to  take  all  of  these  models  and  interface  them  together.  We  want  to  make  sure 
when  somebody  is  talking  about  a  model  we  know  what  level  of  model  it  is.  I  believe 
Dr.  Pugh’s  comments  would  pertain  to  a  model  that  he  would  develop  in  his  shop  to 
answer  questions  on  his  particular  area.  That’s  not  necessarily  the  model  that  would  be 
usable  by  the  Janus  person  who  is  worried  about  putting  the  whole  thing  into  a  large 
simulation. 

LCDR  KELLEHER  (NHRC>.  There  is  no  question  that  the  model  that  Bill  Pugh  is 
developing  on  DNBI  (Disease  and  Non-Battle  Injury)  is  going  to  be  a  very  valuable 
input  that  combat  simulation  modelers  should  be  aware  of.  because  in  fact,  it  is  a  much 
more  sophisticated  view  of  the  generation  of  DNBI  casualties,  which  is  an  output  which 
is  needed  by  the  combat  simulation  modelers.  So  not  only  are  we  defining  inputs  to  a 
model  which  may  be  generated  to  look  at  a  specific  problem,  we  also  have  to  consider 
that  output  needs  to  be  viewed  as  an  input  to  somebody  else. 

DR.  LAUGHERY  (Microanalysis  and  Design):  I  think  we  are  talking  about  two 
kinds  of  models  here.  First  is  the  relationship  between  the  stressors  and  some  types  of 
human  performance,  and  that's  the  stuff  that  people  have  been  doing  for  years  in  the 
lab;  what  I  call  performance  shaping  factors,  performance  degradation  functions. 

What  we  need  then  from  ray  perspective  is  a  matrix  of  models  relating 
psychological  and  physiological  variables  with  different  types  of  performance  tests.  So 
one  of  the  first  things  we  have  to  do  is  define  that  matrix.  You  know,  what  are  the 
stressors  we  are  interested  in  and  how  do  we  went  to  characterize  the  tasks?  This  will 
give  us  all  a  common  framework  to  do  our  research  in.  The  models  for  the  matrix  can 
be  built  in  the  labs  around  the  country.  The  models  don't  even  require  the  collection  of 
field  data  to  build  them.  The  scientific  literature  is  full  of  data  that  could  be  used  to 
build  these  models. 
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The  other  kinds  of  models  are  situation  specific  models,  a  model  of  an  Army 
platoon  in  combat  in  some  particular  combat  environment.  Those  are  the  things  that  the 
users  are  going  to  have  to  do  because  they  are  the  ones  who  want  to  study  that.  From 
my  standpoint  you  separate  those  two  kinds  of  models  out  very  clearly,  then  the 
researchers  can  understand  what  they  have  to  do  and  the  users  can  understand  what 
their  job  is. 

DR.  KOLPCIC  (ABRL);  Understand  what  Dr.  Laughery  said,  which  is  pretty  much 
in  agreement  with  the  statements  that  come  out  of  the  medical  people  here.  That  is,  the 
medical  people  and  their  labs  have  their  job  to  produce  their  data,  to  make  their 
measurements,  to  make  their  model  of  what  happens  as  a  function  of  stressors,  and 
that’s  where  their  job  ends. 

It  is  the  responsibility  of  the  combat  simulation  person  (the  person  making  the  big 
aggregate  model)  to  come  and  get  this  medical  model,  to  learn  enough  about  it  so  that  he 
can  take  the  outputs  from  the  algorithm  and  make  it  produce  a  Delta  at  the  end  of  his 
simulation.  That’s  the  statement  that’s  been  made.  I  think  we  just  ought  to  discuss 
that.  Do  you  think  that’s  really  where  the  responsibility  lies? 

LCDR  KELLEHER  <NHRC>.  Til  be  very  frank.  I  disagree.  And  I’U  disagree  with 
a  very  specific  example.  Lee  Marsh,  who  is  sitting  in  the  back  of  the  room,  is  a  former 
Marine  who  used  to  run  a  TWSEAS  site  and  «s  now  a  contractor  for  the  redevelopment 
of  TWSEAS  software  so  that  it  is  a  more  open  input  system  that  will  accept,  just  as 
Janus  will  accept,  a  variety  of  inputs.  He  didn’t  know  where  to  go  to  get  the  medical 
input  to  be  able  to  modify  his  performance  modules.  We  need  to  have  someone  or  some 
organization  that  brings  these  two  groups  (the  laboratories  and  the  combat  simulators) 
together. 


DR,  KOLPCIC  (ABRL);  The  best  way  to  make  sure  it  won’t  get  done  is  to  escape 
responsibility. 

DIL  HARRISON  (UC  Davis);  The  first  thing  I  noticed  in  the  presentations  W3S  tb** 
not  a  great  deal  wa3  said  about  the  degradation  of  the  opposing  force.  Now  it  may 
assumed  that  that’s  going  on,  but  obviously  the  relative  fitness  of  the  two  forces  is 
important,  not  just  the  fitness  of  our  own  force.  If  you  are  down  to  70%  efficiency,  it’s 
one  thing  if  your  opponent  is  100%,  and  something  else  if  they’re  down  to  30%. 
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The  other  thing  is,  I  would  really  like  to  reinforce  your  suggestion  of  separating 
out  the  cognitive  or  psychological  elements,  both  as  inputs  and  outputs.  A  person  who  is 
very  stressed  may  make  a  very  different  decision,  and  have  a  significantly  greater 
impact  than  someone  with  an  altered  motor  response.  So  I  would  like  to  put  in  a  plug 
for  the  cognitive  element  in  these  various  modeU. 

MR.  PUGH  (MHKC):  What  this  all  makes  me  think  about  is  computer  networking 
and  the  interface  problems  different  systems  have.  With  some  forethought  different 
systems  can  be  plugged  into  the  network  in  a  modular  fashion.  So  I  am  wondering  if 
this  isn't  in  fact  just  a  specific  case  of  that  same  problem.  We  need  to  come  up  with  an 
agreement  of  what  the  plugs  should  look  like  for  the  overall  system  and  have  the 
mutual  understanding  that  the  developers  of  modules  will  produce  programs  that 
interface. 

DR.  KOLPCIC  (ABRL>  That’s  a  nice  idea  in  principal.  Unfortunately,  we  have 
such  a  variety  of  models,  and  the  models  are  much  more  different  than  the  nodes  on  a 
computer  net.  A  model  that  uses  a  brigade  as  its  smallest  element  or  at  least  a  battalion 
as  its  smallest  element,  requires  different  kinds  of  input  than  one  like  AURA  or  Janus 
or  SEES,  in  which  the  smallest  element  is  an  individual.  With  the  individual  I  can  take 
the  output  pretty  directly  from  one  of  Dr.  Naitoh’s  sleep  models,  and  I  know  what  to  do 
with  it.  But  if  I  am  trying  to  do  this  aggregated  over  a  battalion,  somebody  has  to  make 
the  decision  on  how  to  aggregate  the  input  differently,  how  to  aggregate  it 
appropriately. 

DR.  CR1SMAN  (NAMRLk  One  thing  that  has  been  developed  for  '88  is  a  modeling 
committee  with  representatives  from  each  one  of  *he  Navy  medical  labs.  One  of  the 
talks  of  this  committee  will  be  to  compile  a  list  of  data  bases  that  each  lab  has  that  are 
utilizable  for  modeling.  We  will  also  be  looking  at  each  lab’s  resources  and  determining 
what  their  capabilities  are.  This  information  will  then  be  put  together  so  that  the 
committee  will  have  the  information  in  one  spot,  and  th-jy  can  then  act  a*  a  conduit 
between  the  tri-services  and  private  industry.  The  committee  is  just  being  formed  at 
this  point,  but  I  see  it  answering  some  of  the  questions  that  have  come  up  about  how  are 
we  going  to  coordinate  the  modeling  efforts. 

DR.  LAUGHERY  (Microanalysis  and  Design):  At  least  in  the  near  term,  let’s  not 
try  to  build  human  performance  into  brigade  models  and  things  like  that  because  we’ll 
bite  off  more  than  we  can  chew.  I  think  the  place  to  be  right  now  is  at  the  small  unit 
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level.  If  not  one  individual  certainly  a  small  group  of  individuals,  you  know,  like  a  tank 
crew  or  a  fire  team.  I  think  if  we  try  immediately  to  incorporate  human  performance 
in  big  models,  we  are  in  trouble. 

LCDR  KELLEHER  (NHRC):  Well,  you  have  to  know  that  most  of  us  here  feel  the 
same  way.  We  are  crew  based  in  our  concern  and  I  think  we  all  realize  that  our  efforts 
at  the  laboratory  are  never  going  to  extend  beyond  the  analysis  of  the  performance  of 
the  individual  and  the  small  unit. 

DR-  NAITOH  (NHRC):  I  would  really  like  to  reinforce  what  has  been  discussed 
here  about  the  small  models  for  performance.  I  must  tell  you.  however,  that  building  a 
performance  model  is  not  a  trivial  task.  We  did  the  metanalysis  of  the  research 
literature  on  sleep,  and  found  about  500  variables  that  are  involved.  Now,  that's  almost 
impossible  to  deal  with. 

MR.  HAWKINS  (DTRDC):  I  have  a  different  point  of  view.  I  think  rather  than 
looking  strictly  building  from,  the  bottom  up.  from  the  smallest  unit  up,  you  ought  to 
start  simultaneously  looking  from  the  top  down.  If  you  wait  to  ouild  it  from  the 
ground  up,  it’s  going  to  be  ten  years  before  you  can  put  it  on  a  ship  and  show  the  value 
to  the  people  who  need  to  see  it.  Secondly,  I  thought  coming  here  I  would  at  least  walk 
away  with  a  list  of  what  causes  human  performance  degradation.  I  thought  I  would 
have  definitions  when  I  left.  I  thought  I  would  know  somebody  to  call  about  each  of 
those.  And  I  am  not  getting  that. 

LCDR  KELLEHER  (NHRC):  I  did  show  the  slide  yesterday  quickly,  and  it 
certainly  is  nowhere  near  being  all  inclusive,  but  it’s  been  the  areas  that  have  been 
looked  at  in  the  past.  I  also  shewed  the  types  of  physiological  and  psychological 
degrading  factors  that  occur. 

MR.  HAWKINS  (DTRDC):  Along  with  that,  are  there  measures  of  effectiveness 
for  human  degradation?  If  we  don't  agree  with  that,  where  will  that  ever  happen? 
Will  we  all  go  off  and  use  different  things? 

CAPTAIN  J.  HOFFMAN  (NPGS  Monterey,  TRADOC):  I  came  down  here  from 
Monterey  where  I  am  working  on  a  project  designed  to  find  strategies  to  improve  high 
resolution  combat  models  such  as  Janus.  At  the  Naval  Postgraduate  School  and  within 
our  research  group  itself  we  have  the  same  problem  that  David  Taylor  Research  Center 
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is  having.  We  can’t  decide  what  the  important  variables  are.  We  would  like  some 
answers  from  the  research  community.  When  you  build  a  computer  driven  model  you 
are  limited  for  practical  reasons  of  hardware  and  memory  in  what  you  can  do  and  still 
have  a  workable  model.  What  variables  do  we  need  to  include  that  make  the  most 
difference?  If  you  talk  to  the  operational  community  you  don’t  get  any  real  answer, 
and  if  you  read  the  literature  you  get  a  million  variables.  That  is  one  of  the  reasons 
why  the  users  and  designers  of  high  resolution  models  have  not  been  really  interested  in 
incorporating  human  factors  as  a  broad  class  into  those  models,  because  we  don't  know 
where  to  start.  I  would  be  more  than  happy  to  talk  to  anybody  who  had  any  theory, 
idea  or  suggestion  on  where  to  start. 


Perhaps  sleep  deprivation  is  a  place  where  you  could  say  that’s  a  broad  class  and 
we’ll  start  there.  I  would  even  limit  it  further.  I  would  say  what  does  sleep  deprivation 
do  to  target  acquisition?  If  somebody  could  build  a  functional  relationship  or  perhaps 
some  interpolated  data  or  table  that  would  be  usable,  but  guess  what,  nobody  has  done 
tliat  yet.  and  that's  where  we  are  at. 

DR.  LAUGHER Y  (Microanalysis  &  Design):  Captain  Hoffman’s  got  it.  That’s  what 
I  said  before  in  a  less  direct  way.  The  stressor  variables  listed  along  the  top  of  the 
matrix  I  described  have  to  be  the  vaiiable  that  matter.  What  are  those  variable 
stressors  on  human  performance?  That’s  where  we  need  to  focus  our  attention. 


LCDR  KELLEHER  (NHRC):  Let  me  pose  the  counterpoint  that  if  you  did  that 
limited  analysis  of  stressors  on  limited  functions,  then  I  would  have  to  ask  you  as  a 
researcher  what  does  that  mean  to  the  combat  task  performance,  which  is  what  is 
actually  being  modeled. 


DR.  KOLPCIC  (ABRLh  Deltas.  That’s  what  you  want  to  know.  Delta. 


MAJOR  ANDERSON  (TWSEAS):  Within  TWSEAS,  the  biggest  deficiency  is  the 
lack  of  human  performance.  You  know,  electrons  (like  I  said  yesterday)  run  24  hours  a 
day  and  they  never  get  tired. 


To  correct  that,  I  think  we  should  start  both  at  the  bottom  and  at  the  top.  If  you 
don’t  start  at  the  top,  we  will  all  be  retired  and  probably  dead  by  the  time  it  finally 
shows  up.  As  a  user,  I  am  willing  to  accept  just  about  anything  that  puts  more  realism 
in  our  model  It  doesn't  have  to  be  exact,  it  does  not  have  to  be  perfect.  I  don’t  need 
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something  so  damn  complicated  that  I  can’t  use  it.  That  doesn’t  do  me  any  good.  That 
doesn’t  do  the  people  I  am  working  with  any  good.  Lee  Marsh  is  putting  something  of 
that  in  the  revision  of  TWSEAS,  but  we  still  have  a  hell  of  a  long  way  to  go.  Right  now 
anything  is  better  than  what  I  have. 

CDR  CONTRERAS  (ONT):  I  agree  with  you  100%.  One  of  the  biggest  headaches  we 
have  in  the  laboratories  is  trying  to  take  a  model  and  tweak  it  and  tweak  it  and  tweak  it 
to  get  100%  resolution  of  the  problem  when  80%  will  do.  You  need  to  get  that  thing  out 
in  the  fleet  as  soon  as  possible.  The  time  and  cost  of  tweaking  that  model  from  90%  to 
95%  is  enormous,  and  to  go  from  95%  to  99%  is  even  much  greater.  If  you  are  going  to 
keep  the  technology  in  the  laboratory  until  you  get  that  99%  figure,  by  the  time  you  get 
it  out  to  the  fleet  it  will  be  obsolete.  So  get  something  out  there  as  soon  as  you  can  for 
the  user  to  use  and  then  continue  working  on  it  and  build  on  it,  but  after  it’s  out  there. 
Because  80%  of  something  is  much  better  than  0%  of  nothing. 

MR.  PUGH  (NHRC>.  I  would  like  to  throw  this  ball  back  to  the  other  side  in  the 
sense  that  before  we  can  say  what  causes  it  I  think  we  on  the  "our"  side  have  to  get  a 
better  idea  of  what  it  is.  One  suggestion  was  that  target  acquisition  as  a  human 
performance  was  important.  I  think  if  we  had  a  list  of  criteria  such  as  target  acquisition 
or  firing  rate,  etc.,  we  could  develop  relationships  between  the  criteria  and  a  list  of 
human  factors.  Until  we  do  that  we  don't  know  whether  the  human  factors  relate  to 
criteria. 

LCDR  KELLEHER  (NHRC):  Well,  again,  harkening  back  to  the  Intermediate  Dose 
Program,  that  was  essentially  done  in  the  early  3tages  of  that  program.  In  the 
Intermediate  Dose  Program  the  Defense  Nuclear  Agency  knew  that  it  could  not  define 
for  the  Army  what  were  the  essential  things  that  the  Army  thought  were  important  and 
needed  to  be  done  on  the  battlefield.  So  the  Defense  Nuclear  Agency  went  to  the  Army 
and  said,  "all  right,  we  can’t  do  everything,  what  are  the  essential,  most  highest  pay-off 
combat  tasks  that  we  should  analyze  for  you  to  get  a  better  estimate  of  performance 
degradation  on  the  battlefield?  Probably  the  same  thing  needs  to  be  done  with  the  Navy 
and/or  the  Marine  Corps.  We  actually  have  a  contract  right  now  which  is  being  let  in 
San  Francisco  and  will  identify  those  tasks  for  us  infantry  riflemen. 

To  my  knowledge,  we  don’t  have  an  identified  set  of  combat  tasks  shipboard.  That 
should  be  our  emphasis.  Maybe  we  need  to  do  that.  What  are  the  crew  tasks  that  are 


performed  shipboard  that  will  have  the  highest  pay-off  given  a  scenario  dependent 
engagement? 

DR.  PAUL  KIRK  (NSDC):  Dr.  Rodonwyn  Carson  at  NTSC  over  in  Orlando. 
Florida,  is  doing  essential  task  analysis  on  shipboard  tasks  and  she  might  be  a  good 
contact. 

DR.  SHELDON  LEVIN  (Technical  Southwest);  I  was  very  impressed  with  the  book 
that  was  put  together  by  Burton  Banks,  et  al.  They  did  an  interesting  thing  which  I 
hadn’t  seen  done  with  models  before,  and  that  is  they  tried  to  put  them  in  a  very 
systematic  way.  It  kind  of  asks  the  same  questions  about  each  of  these  models,  and  I 
was  impressed  with  that  effort.  1  had  not  seen  anything  like  this  done  before.  Now,  the 
same  thing  needs  to  be  done  tor  the  biological  models. 

There  are  people  that  will  model  performance  degradation  Get’s  say  from 
radiation)  by  saying,  at  no  radiation  the  performance  is  KXfc  i  and  we  know  that  a  450 
rad  exposure  will  kill  you  free  and  clear,  so  we'll  say  it’s  0%  performance  at  that  point, 
and  let  us  draw  a  straight  line  in  between  to  describe  a  degradation  function.  I  made  up 
this  example  because  I  want  to  make  a  point.  Nobody  would  actually  do  anything  that 
crude,  although  I  have  seen  things  done  almost  that  crude,  and  they  were  called  models. 
At  the  other  end  of  scale  we  have  complex  models  like  AURA.  Data  for  this  model  was 
gathered  from  a  wide  variety  of  sources.  One  source  was  the  IDP  program,  which  had 
the  efforts  of  about  20  people  for  about  six  years  devoted  to  producing  some  very  nice 
results,  and  that’s  only  one  input  that  went  into  the  AURA  model. 

My  plea  here  is  for  some  kind  of  equivalent  look  and  summarization  of  the  kinds  of 
performance  models  that  people  have  built.  It  would  really  be  important  to  have  an 
honest  evaluation  that  describes  what  went  into  each  model.  Was  it  really  based  on 
actual  measures  taken  on  10,000  people  sleeping,  or  was  tliis  based  on  an  epidemiology 
study,  or  was  it  based  on  a  conjecture  of  an  engineer.  I  think  the  publications  put 
together  for  this  meeting  would  really  be  tremendously  helpful  to  me,  and  I  suspect  to 
others,  and  for  tliis  meeting;  it’s  an  excellent  start.  I  plead  for  the  same  kind  of  thing 
for  the  human  performance  models. 

DR  NORM  LANE  (Essex  Corporation):  I  have  been  encouraged  by  the  free  flow  of 
information  taking  place  here,  but  I  am  getting  a  little  bit  discouraged,  because  it  makes 
me  tired  to  think  about  taking  all  of  the  tasks  that  any  military  person  might  do  and 
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lining  them  up  along  one  axis  of  a  matrix,  because  there  is  going  to  be  20  or  30  or  40,000 
of  them.  Then  to  try  and  make  estimates  of  degradation  as  a  function  of  a  half  dozen 
matrix  stressors  seems  like  almost  an  impossible  task.  Most  of  the  things  that  military 
people  do  are  probably  made  up  of  perhaps  two  or  three  major  performance  factors. 
Those  are  probably  reasonably  well  understood.  I  think  what  we  need  is  something  like 
a  dosage  equivalency  model  for  each  of  those  stressors  that  maps  them  into  something 
that  looks  quite  a  bit  like  what  came  out  for  ionizing  radiation.  Once  you  have  got  that, 
you  can  put  everything  into  the  same  framework.  You  can  show  it  to  people,  and  it’s  a 
piece  of  cake  to  implement  the  model. 

Performance  variables  probably  need  to  be  organized  around  something  very  simple 
like  cognitive  and  motor  performance.  Most  of  the  human  performance  models  I  have 
seen  working  in  the  bigger  models  use  something  really  dumb  like  cognitive,  motor, 
visual,  etc.,  and  those  tend  to  work.  When  they  get  more  complex  than  that,  they  start 
collapsing  under  their  own  weight.  So  I  would  at  least  advocate  trying  to  get  a  common 
matrix  like  time  and  a  common  dosage  equivalency  model.  Anybody  should  be  able  to 
do  that  as  medical  people.  That’s  where  it  came  from,  and  then  we  can  talk  about 
whatever  stressor  you  wish  to  talk  about  and  make  them  equal.  It  also  makes  the 
combined  stressor  discussion  a  hell  of  a  lot  easier. 

LCDR  KELLEHER  (NHRC):  George  Anno,  would  you  agree  that  without  the 
additional  validation  steps  that  are  anchored  on  combat  task,  performance  would  be 
acceptable? 

MR.  ANNO  (Pacific-Sierra):  I  think  it’s  a  great  idea,  but  let  me  tell  you  what 
happened  to  us  when  we  tried  to  identify  the  specific  performance  tasks  that  are 
needed.  After  a  military  meeting  at  TRADOC  that  dealt  with  military  tasks  we  got  the 
behaviorists  together  to  get  their  blessing  on  a  set  of  basic  performance  tasks.  Well, 
that  was  the  biggest  cat  and  dog  fight  we  had  ever  had  in  our  life.  People  actually  got 
up  on  the  table  just  about,  and  were  pounding  and  everything,  so  if  you  are  going  to  do 
that,  you  are  going  to  have  to  sort  of  select  your  behaviorists  in  some  way.  Because  if 
you  don't,  no  one  is  going  to  be  able  to  agree  on  a  taxonomy  of  performance  tasks. 

I  think  we  finally  ended  up  doing  our  own  taxonomy,  which  is  sort  of  a 
taxonomical  subset,  and  is  more  or  less  geared  to  the  stuff  we  needed  to  do.  We  had  to 
really  get  down  to  fundamental  definable  things  that  those  Army  guys  can  understand. 
If  you  are  ever  going  to  go  out  to  the  fleet,  service  those  people,  and  cooperate  in  your 
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study,  you  are  going  to  have  to  deal  in  tasks  and  terminology  they  understand.  We  gave 
up  on  this  marvelous  behavioral  taxonomy  thing  and  did  our  own  taxonomy  and  that 
seemed  to  work.  But  I  agree  in  principal  with  this  approach,  no  question  about  it.  It  is  a 
beautiful  academic  approach,  but  you  are  going  to  have  to  fight  a  lot  of  battles  in 
between  and  compromise,  no  question. 


DR.  LAUGHERY  (Microanalysis  &  Design):  The  way  I  think  of  it,  because  I  have 
been  there  before,  is  just  pick  a  taxonomy,  any  taxonomy  and  just  stick  with  it.  There 
are  lots  of  famous  behaviorists  and  each  has  his  own  taxonomy.  Just  pick  a  taxonomy 
and  stick  with  it.  because  that  gives  everybody  a  common  framework.  The  joint  working 
group  that  sponsored  MicroSAINT  spent  a  lot  of  time  preparing  a  taxonomy.  Dr.  Ed 
Fleishman  was  one  of  the  individuals  that  worked  on  the  project. 

MAJOR  ANDERSON  (TWSEAS):  I  think  some  type  of  standardisation  is  desirable. 
Certainly  it  decreases  the  amount  of  misunderstanding. 


DR.  EARL  ALLUISI:  One  of  the  ways  of  approaching  the  topic  we  are  discussing 
right  now  is  to  start  at  the  other  end.  Start  with  combat  simulation  models  and  find  out 
what  is  important  to  the  outcome.  I  would  like  to  get  behaviorists  on  the  side  of  the 
combat  simulation  modelers,  and  let’s  identify  some  of  the  systems  that  we  think  are 
affected  by  human  performance.  Psychologists  say  sortie  rate  will  be  influenced  by 
human  performance.  Certainly  that's  going  to  be  affected  by  human  performance  both 
in  terms  of  the  quality  of  the  maintenance  people  who  are  turning  around  the  aircraft 
and  their  momentary  condition  in  terms  of  fatigue  or  other  stresses.  Now  perform  a 
very  simple  sort  of  sensitivity  analysis  using  the  combat  simulation  model.  Let's  go  in 
and  see  what  the  outcome  of  the  battle  is;  day  one,  day  two,  day  three,  day  four,  day 
five,  with  the  human  performance  program  set  at  two  and  one  half.  If  you  double  it,  if 
you  half  it,  does  it  have  any  effect?  What  effect  does  it  have?  Then  do  that  for  several 
other  primers  that  we  think  will  affect  the  outcome.  One  study  has  done  this,  Sid 
Dutchman  did  it  at  IDA,  but  the  publication  is  not  out.  He  used  the  TACWAR  model 
and  varied  several  of  the  parameters  to  determine  what  affect  it  would  have  on  the 
major  criterion,  movement  of  the  tank  in  the  field.  If  we  did  this  for  our  sortie 
example  you  would  probably  find  that  sortie  rate  doesn’t  have  any  effect.  If  you 
understand  how  the  Air  Force  is  going  to  fight  the  war  where  their  first  days  of  combat 
are  devoted  to  neutralizing  their  threat,  then  you  can  understand  that  sortie  rate  would 
not  have  an  effect  on  a  ground  war.  There  are  other  things  that  have  a  major  effect  on 
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a  ground  war,  but  sortie  rate  doesn’t.  Rate  of  fire.  Is  that  affected  by  human 
performance?  Or  is  it  completely  determined  by  the  equipment?  I  think  it’s  affected  by 
human  performance,  and  I  think  rate  of  fire  will  probably  turn  out  to  have  a  greater 
effect  on  the  ground  war  if  you  alter  the  human  performance  module  in  your  combat 
simulation  model. 

Let’s  stay  on  this  approach  for  a  while  longer.  Now  we  have  identified  some 
important  systems  that  will  really  affect  the  outcome  of  a  combat  engagement  in  at 
least  as  simulated  by  our  model.  We  assume  the  model  is  good,  correct,  validated  or  can 
be  validated.  Now  comes  the  guidance  for  the  laboratory  because  once  you  identify 
critical  systems,  the  modeler  will  have  to  get  with  other  scientists  and  get  the 
appropriate  algorithm  or  function.  At  this  point  it’s  not  merely  using  a  factor  of  two.  I 
would  like  to  know  at  this  point  what  the  effect  is  going  to  be  as  a  functional  relation  in 
terms  of  outcome  of  military  value.  That’s  the  way  (from  my  point  of  view)  that  we 
can  get  started  on  this  project  and  not  waste  a  lot  of  time  on  stuff  that  doesn’t  really 
matter.  We  can  identify  the  most  important  things  that  are  going  to  affect  military 
outcomes.  That’s  the  name  of  the  game;  what  is  the  outcome! 

As  for  the  Naval  Health  Research  Center,  you  can  pay  your  way  for  the  next  ten 
years  easily  on  one  good  identification,  and  you  can  do  that  because  I  know  that  human 
performance  is  going  to  affect  the  outcome  on  some  of  those  systems.  The  next  step  is 
what  does  it  cost  to  do  that?  Say  we  are  dealing  with  protective  clothing.  To  give  them 
protective  clothing  or  to  give  them  additional  training,  or  to  have  more  stringent 
selection  or  to  put  twice  the  number  of  people  in  the  system;  so  you  have  redundancy  of 
people  like  redundancy  of  equipment,  what  does  it  cost?  What  are  the  benefits  in  terms 
of  military  value?  What  does  it  do  to  the  outcome?  Now,  let’s  also  compare  that  with 
alternative  ways  of  getting  the  same  outcome  through  some  other  variable.  Take  "rate 
of  fire,"  for  instance.  I  can  change  it  by  getting  a  new  weapon  or  getting  a  new 
weapons  system,  and  I  could  now  begin  to  do  what  we  have  all  said  we  should  be  doing, 
get  real  trade-off  analyses.  What  does  it  cost;  what  is  the  effectiveness  of  doing  it  by 
twice  the  number  of  people  with  these  guns,  or  600  ships  instead  of  300  ships.  With  this 
type  of  model  and  analysis  maybe  we  can  start  to  get  some  reasonable  decisions. 

The  credibility  of  these  future  derision  will  be  based  on  military  value.  Combat 
simulation  modelers  are  going  to  bs  some  of  the  most  important  people  in  my  world, 
because  I  think  that’s  the  only  handle  I  have  on  this  type  of  trade-off  analysis.  I  would 


like  to  give  you  a  general  overview  of  our  organization.  The  Department  of  Defense  is 
made  up  of  the  Office  of  the  Secretary  of  Defense,  the  defense  agencies,  the 
Organization  of  the  Joint  Chiefs  of  Staff,  the  unified  commands,  and  the  military 
departments.  That’s  the  Department  of  Defense.  Within  that  organization  OSD  (Office 
of  the  Secretary  of  Defense)  has  three  jobs,  two  written  and  one  implied.  The  first  job 
is  to  establish  the  policy  under  which  the  military  department  is  operating.  The  R&D 
side  establishes  R&D  policy.  Secondly,  we  provide  oversight.  That  means  we  watch  how 
they  are  executing  their  program,  and  insure  that  it  is  consistent  with  OSD  policy.  The 
third  part  which  is  not  usually  written  up,  but  which  I  think  is  the  mo3t  important,  is 
advocacy.  I  tell  the  people  in  the  SAT  (Science  and  Technology)  reviews  that  their  first 
job  is  to  get  their  program  into  the  budget.  That  means  you  have  to  get  together  in  the 
R&D  community  along  with  the  operational  user  community,  and  develop  a  unified 
advocacy  within  your  community.  Because  unless  you  are  in  the  budget,  my  hands  are 
tied.  I  can’t  do  anything.  Once  you  are  in  the  budget,  then  I  can  do  lots  of  things. 

Most  of  the  things  that  I  can  do  easily  are  negative.  The  things  that  will  boost  your 
program  along  take  a  little  more  effort,  and  that  rarely  gets  done.  We  can  tell  the 
Navy  that  they  don’t  have  enough  support  in  a  given  area,  and  they  should  do  more,  but 
it's  got  to  be  done  a  certain  way  because  if  OSD  tells  the  services  to  do  anything,  they 
tend  to  tighten  up  and  3tonewall  the  effort. 

There  are  some  changes  going  on  this  year  that  you  ought  to  be  aware  of.  We  ail 
expect  defense  spending  to  go  down,  and  what  happens  when  total  funding  goes  down  is 
R&D  goes  down  by  a  greater  percentage,  and  when  R&D  goes  down  environmental  life 
sciences  go  down  by  even  a  greater  percentage.  So  coming  full  circle,  one  of  my  jobs  is 
to  protect  R&D  programs.  To  advocate  and  protect  the  programs  of  all  the  military 
departments  in  my  domain,  in  our  little  directorate  there  are  five  of  us  and  we  cover 
mechanical  warfare,  environmental  projection,  environmental  considerations-which  is 
primarily  meteorologist,  biomedical,  and  training  and  personnel.  The  biomed  area  is 
covered  by  Captain  Ray  Spkar  from  the  Navy.  We  work  closely  together  and  split 
certain  of  the  program  elements. 

We  now  work  under  the  Novar  Nichols  Act.  We  used  to  have  an  Undersecretary 
for  R&D,  and  our  program  was  in  the  engineering  section.  A  new  Undersecretary,  the 
Undersecretary  for  Acquisition,  was  created,  and  the  Director  of  Defense,  Research  and 
Engineering  will  be  recreated  and  will  report  to  the  Undersecretary  for  Acquisition. 
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Until  this  year  the  policy  was  to  have  the  services  brief  RSD  as  to  what  its 
investment  strategy  was.  This  year  they  turned  it  around  and  RSD  is  going  to  brief  the 
services  on  its  visions  and  goals.  The  direct.  i  has  asked  each  of  us  to  put  together  a 
program  that  will  go  in  DOD’s  Science  and  Technology  Advocacy  book,  which  will  be 
taken  to  the  four  committees  in  Congress  that  are  important  for  us.  In  putting  together 
DOD’s  visions  and  goals,  we  had  to  be  specific  and  we  had  to  give  estimates  of  the 
payoff.  We  had  to  provide  very  clear  directions  as  to  the  effects  the  effort  would  have 
on  military  capability. 

Number  one  in  combat  mission  tactical  training  is  a  program  that  emphasizes 
networking  of  simulators  for  training,  but  also  for  situational  awareness,  for  mission 
rehearsal  and  possibly  as  a  battle  management  aid.  I  think  this  initiative  is  going  to  be 
one  that  the  director  is  going  to  push,  it's  the  one  that’s  closest  to  what  we  are  talking 
about  here  today.  Remember  however,  I  said  training  because  that’s  in  my  title  and 
they  understand  that.  But  training  is  always  in  my  usage  a  very  broad  term.  It 
includes  all  of  the  human  performance  aspects,  including  the  degradations,  the 
avoidance  of  the  degradation  or  enhancement  that  we  can  get  through  all  the  techniques 
that  we  have. 

I  think  we  can  come  out  of  the  program  reviews  in  good  stead  if  we  keep  ourselves 
product  oriented.  We  have  got  to  be  specific  in  terms  of  the  deliverables  that  we  are 
going  to  produce.  That  means  measure  and  evaluate  in  terms  of  military  value.  That’s 
the  way  we  can  survive  and  probably  the  only  v/ay  we  can  sumve.  An  important  piece 
of  this  initiative  is  a  transition  plan.  If  you  do  the  first  part  of  the  development  and 
don’t  keep  tying  it  in  with  the  user  and  insist  that  the  user  keep  tying  in  with  you  in  a 
meaningful  way,  the  program  will  at  best  be  delayed  and  at  worst  die.  I  insist  that 
before  we  put  any  big  money  into  a  development  that  we  have  written  agreement  from 
the  user  at  an  appropriate  level.  For  example,  if  it’s  a  training  technology  to  go  to  a 
school,  then  1  get  at  least  a  Two  Star  Admiral  from  TRADOC,  and  a  Two  Star  General 
from  the  Training  Command  to  agree  that  if  the  technology  is  successful  during  the 
demonstration  field  test  and  evaluation,  we  will  implement  it.  Then  they  say,  "what 
happens  when  it  comes  in  this  year  and  funding  requirements  are  higher,  I  said  tliat’s 
your  decision."  You  do  what’s  best  for  your  service. 
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That’s  what  I  mean  when  I  say  get  together  with  the  user.  Not  a  junior  officer 
teaching  a  course  in  the  school,  not  a  junior  physician  who  is  walking  the  ward  of  a 
hospital.  You  have  got  to  get  to  a  user  who  has  the  authority  to  make  it  aappen,  and 
get  his  commitment  that  he  will  implement. 

LCDR  KELLEHER  (NHRC):  I  am  not  sure  how  we  come  together  and  summarize 
the  outcome  of  this  meeting. 

DR  LAUGHERY  (Microanalysis  &  Design):  One  way  we  could  probably 
summarize  the  meeting  is  if  we  summarized  some  of  the  basic  questions  that  people  had 
that  are  leaving  here  unanswered,  and  then  also  these  that  they  had  that  have  been 
answered. 

LCDR  KELLEHER  (NHRC):  Thank  you.  That's  an  excellent  suggestion.  Which 
questions  were  not  answered  based  upon  the  expectations  that  you  came  to  the  meeting 
with?  Jack  Hawkins,  you  have  already  suggested  that  there  are  several  that  you  had  and 
that  you  thought  you  would  get  an  answer  for. 

MR  HAWKINS  (DTRDC):  I  don't  know  what  the  measures  of  degradation  are, 
and  the  meeting  hasn’t  clarified  that  for  me.  I  would  like  to  see  an  all-inclusive  list  of 
factors  that  degrade  human  performance.  I  would  also  like  to  see  the  list  weighted  by 
which  ones  are  most  important. 

MR  ANNO  (Pacific-Sierra):  I  thought  we  didn’t  really  touch  enough  on  validation, 
which  gets  into  the  measurements  you  arc  really  interested  in.  It  just  seems  like 
validation  is  the  bottom  line.  Validation  is  the  thing  most  operational  people  are 
interested  in.  You  have  got  to  convince  people  that  the  model  really  works. 

LCDR  KELLEHER  (NHRC):  Should  there  be  an  identification  of  criterion  of 
validation,  or  a  criterion  for  inclusion  of  degradation  factors,  or  a  criterion  for  inclusion 
of  a  performance  decrement  factor?  Should  these  be  things  that  have  identified  criteria 
that  everybody  agrees  on? 

DR  TERHUN2  (LLNL):  I  really  feel  like  I  need  to  learn  a  lot  more  about  the 
human  degradation  factor:,  and  the  human  factors  that  cause  people  to  behave  in 
different  ways  than  expected,  depending  upon  the  stresses  that  are  put  on  them.  1  don’t 
have  a  good  understanding  of  that  process,  so  I  am  going  to  have  to  learn  a  lot  about 
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that  before  I  can  begin  to  think  about  how  that's  going  to  be  modeled.  I  think  also  that 
a  lot  of  the  researchers  that  have  a  better  understanding  of  that  need  to  learn  a  little  bit 
about  modeling  in  order  to  understand  how  the  direction  of  their  measurements,  and 
their  tests  and  their  experiments  are  to  go. 

I  think  Dr.  Alluisi  brought  up  an  important  point.  There  is  no  sense  in  making 
detailed  measurements  on  stuff  that’s  not  important  in  the  primary  analysis.  I  think  we 
need  to  attack  those  things  that  are  most  important  first,  learn  from  them  as  we  go, 
build  very  crude  simple  models  to  start  with,  and  then  define  them  as  we  go. 

So  1  would  suggest  that  we  have  another  meeting  in  six  months  and  that  in  the 
meantime  people  prepare  some  papers  on  some  of  these  areas  so  that  we  can  begin  to 
learn  from  each  other. 

MR.  ANNO  (Pacific-Sierra):  I  think  between  now  and  six  months  from  now  you 
could  summarize  what  we  have  done  here  and  use  the  Delphi  technique  among3t  the 
attendees  to  get  a  consensus  ready  for  the  next  meeting.  That  would  put  us  a  lot 
further  along  in  understanding  each  other  and  kaving  unified  definitions. 

CAPTAIN  HOFFMAN  (NPGS,  Monterey,  TRADOC  >.  I  would  like  to  know  more 
about  the  specifics  of  the  models,  (the  existing  weapons  models)  and  what  programs  are 
involved  so  I  can  get  an  idea  which  programs  may  be  affected  by  human  performance. 
I  don’t  think  this  meeting  has  given  me  enough  knowledge  in  these  areas. 

MR.  ANNO  (Pacific-Sierra):  I  think  if  modelers  sat  down  and  listed  some  of  the 
human  performance  issues  they  are  facing  as  modelers,  it  would  help  define  the 
problem.  If  the  modeler  then  had  an  organization  or  group  of  individuals  to  turn  to 
that  could  look  at  his  list  and  say,  well,  you  know,  this  is  not  realistic,  this  relationship 
just  doesn’t  exist,  or  it  does  exist,  or  we  have/haven’t  quantified  it,  things  of  that 
nature.  With  that  type  of  feedback  and  exchange  back  and  forth  we  could  start  to 
learn,  both  conununities  will  begin  to  learn. 

MR.  STROM:  As  a  model  developer  I  would  like  to  know  what  are.  the  things  of 
concern  to  the  users  of  the  models.  We  have  found  that  it’s  sometimes  difficult  to  get 
enough  information  on  what  it  is  the  user  wants.  To  give  one  specific  example,  in  the 
SEES  project,  we  are  talking  about  item  level  resolution,  human  versus  human,  how 
important  is  marksmanship  to  analyzing  an  assault,  and  if  marksmanship  is  important  to 


the  outcome,  then  how  does  fatigue  impact  upon  marksmanship?  Finding  data  to  answer 
this  type  of  question  is  at  best  (and  often)  impossible.  So  I  agree  with  several  comments 
that  have  been  made  90  far.  and  that  is  there  needs  to  be  more  direction  from  the  user 
to  the  developer. 

MR.  HAWKINS  (DTRDC):  What  if  we  were  really  successful  in  making  this  an 
important  aspect  of  design  of  military  weapons  systems.  I  think  we  would  have  to  end 
up  at  some  point  being  part  of  the  development  process,  and  this  might  be  a  way  to 
focus  the  effort. 

DR.  HARRISON  (UC  Davis):  You  might  really  want  to  encourage  people  to  write 
in  with  suggestions,  particularly  if  there  is  going  to  be  a  follow-up  meeting,  I  love  this 
idea  of  the  Delphi  technique. 

LCDR  KELLBHER  (NHRC>.  One  suggestion  that  was  made  by  Lawrence 
Livermore  is,  they  serve  as  a  i  tearing  house  for  information  exchange.  They  have  the 
capability  of  setting  up  a  global  electronic  network  of  modelers  and  performance 
investigators.  Would  that  be  something  that  would  be  helpful  to  set  up  in  addition  to 
other  mechanisms? 

CAPTAIN  JONES  (NMRDCh  I  think  that  from  my  perspective  what  I  need  to  do 
is  get  a  much  clearer  notion  as  to  the  vehicles  that  we  have  currently  in  place,  in  order 
to  come  to  grips  with  an  effective  vehicle  that  will  do  what  we  want  done  with  it.  We 
have  a  DOD  working  group  in  modeling.  Why  can’t  we  use  that  vehicle  rather  than 
developing  another  sort  of  vehicle? 

We  have  a  lot  of  these  committees,  working  groups,  whatever  you  want  to  call 
them,  that  J\ave  as  their  primary  charter  the  exchange  of  information  with  in-services 
and  cross-services.  At  some  point  in  the  future  we  should  come  to  grips  with  what 
would  be  the  appropriate  vehicles  for  the  management  of  the  modeling  research 
programs  under  the  cognizance  of  NMRDC.  We  will  develop  this  strategy  over  the  next 
few  months. 

LCDR  KELLEHER  <NHRC>.  I  would  personally  like  to  thank  you  all  for  coming 
to  this  meeting  and  contributing  your  ideas  to  what  premises  to  be  an  exciting  new 
technological  area. 
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The  joint  Navy/Lawrence  Livermore  meeting  (JAMCSI)  was  held  at  Lawrence 
Livermote  National  Laboratory  on  November  30  and  December  1,.  1338.  The  meeting 
was  intended  to  bring  together  individuals  from  two  different  research  communities: 
the  combat  simulation  and  war  gaming  community,  and  the  human  performance 
community. 

It  was  intended  that  the  meeting  provide  a  form  for  the  exchange  of  ideas  and 
concepts  with  the  ultimate  objective  of  improving  the  fidelity  of  combat  simulation 
modelling. 

As  background  for  the  meeting  two  publications  were  given  out  to  each  attendee: 

"Review  and  analysis  of  the  literature  in  the  area  of  human  performance 
modelling,”  UCID  21 558,  Lawrence  Livermore  National  Laboratory,  November, 
1988. 

"An  inventory  of  wargaming  models  for  special  warfare:  candidate  applications 
for  the  infusion  of  human  performance  data,"  UCID  21551,  Lawrence 
Livermore  National  Laboratory,  November,  1988. 

The  first  day  of  the  meeting  was  devoted  to  presentations  on  existing  combat 
simulation  models  and  their  attempts  to  incorporate  human  performance  information. 
Speakers  provided  an  overview  of  some  of  the  more  widely  used  models  and  outlined 
the  rational  for  the  model's  development,  its  current  use,  and  the  strategy  being  used 
to  incorporate  human  performance  information. 


The  list  of  topics  and  speakers  were  as  follows: 


Human  Performance  Research 
at  the  Naval  Health  Research 

Captain  Chaney 

NHRC  Center 

Overview  on  Navy  Modelling 

Needs 

Captain  Jones 

NMRDC 

Meeting  objectives  and 
organization 

LCOR  Kelleher 

NHRC 

JANUS  Model 

Dr.  Toms 

ILNL 

Crew  III 

Mr.  Anno 

Patific-Sierra-Eaton 

SEES  Model 

Dr.  Terhune 

LLNL 

TWSEAS  Model 

Maj.  Anderson 

USMCB  Pendelton 

AURA  Model 

Dr.  Ko!pdc 

ABRL 

NURA  Model 

Dr.  Yencha  &  Dr.  Kirk 
NSWC 

Micro  SAINT 

Dr.  Laughery 

Micro  Analysis  &  Design 

SHiPDAM 

Mr.  Hawkins 

DTRC 

Human  Factors  Modelling 
Requirements 

CDR  Contreras 

ONT 

The  evening  dinner  speaker  was  Col.  John  Pickering  (USAF  Ret.)  and  he  provided  a 
historical  perspective  to  the  development  of  the  mifitary's  interest  in  combat  simulation 
modelling. 

The  second  day  of  the  meeting  was  to  be  devoted  to  future  combat  simulation  models 
and  work  groups  were  requested  to  deal  with  design  and  specification  issues.  The 
original  agenda  had  to  bo  abandoned  when  it  became  apparent  that  there  were 
several  issues  that  needed  to  be  addressed  by  the  entire  group.  Before  the  meeting 
was  opened  to  general  discussion  Commander  Tom  Contreras  from  the  Office  of  Navy 
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Technology  gave  a  presentation  on  the  organization  and  structure  of  the  research 
administrative  environment  and  the  hurdles  that  faced  any  new  research  initiative. 

The  open  discussion  was  completed  with  a  short  presentation  by  Dr.  Earl  Alluisi  from 
the  Office  of  the  Under  Secretary  of  Defense.  Dr.  Alluisi  indicated  his  strong  support 
for  computer  modelling  and  the  use  of  combat  simulation  for  evaluating  various 
defense  alternatives.  He  said  that  he  was  supporting  a  major  research  thrust  in  this 
area  because  of  the  wide  spread  potential  for  this  technology. 

To  bring  you  up-to-date  on  the  Navy/LLNL  meeting,  I  would  like  to  summarize  some  of 
the  major  points  made  by  the  presenters  at  the  meeting. 

Captain  Chaney  outlined  the  numerous  human  performance  programs  currently 
underway  at  NHRC  and  indicated  that  these  research  programs,  along  with  the 
individual  researchers  involved,  were  available  to  support  the  combat  simulation  effort. 
He  felt  that  the  human  performance  research  that  is  going  on  in  the  Navy  medical 
laboratories  was  an  untapped  resource  and,  that  if  appropriately  applied,  could 
enhance  the  fidelity  of  combat  simulation  models. 

Captain  Jones  directed  most  of  his  comments  to  human  performance  databases.  He 
indicated  that  several  Navy  laboratories  were  using  the  MICRO  SAINT  software 
product  to  organize  and  develop  human  performance  information.  He  felt  that  the 
human  performance  modelling  development  in  the  past  had  been  hampered  by  both 
hardware  constraints  and  the  lack  of  user  friendly  software,  but  that  both  of  those 
barriers  had  now  been  over  come  and  that  it  was  now  time  to  develop  the  supporting 
data  modelers  wiil  have  to  deal  with: 

1 .  The  goal  of  the  model. 

Modelers  need  to  identify  the  users  and  bring  them  into  the  development 
process  early. 

2.  How  good  is  the  modal? 

The  model  has  to  make  things  easier  for  the  user  and  the  user  has  to  be 
able  to  believe  in  the  results.  To  do  this  we  must  make  sure  he  knows 
what  assumptions  went  into  the  model  and  he  must  know  that  the  results 
are  valid. 

3.  What  databases  are  available? 

We  need  a  major  effort  to  bring  together  the  various  fragmented 
databases  and  make  them  generalizable  for  use  in  the  various  models. 

4.  How  do  you  get  fleet  support? 

Captain  Jones  suggested  that  there  are  four  elements  in  getting  fleet 
support.  They  are: 
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a.  Existence  of  a  valid  requirement. 

b.  An  identified  user. 

c.  integration  within  existing  technology  base. 

d  A  transition  plan  for  moving  the  technology  along. 

LCDR  KELLEHER 

In  outlining  the  objectives  of  the  meeting  LCDR  Kelleher  indicated  that  one  of  the  main 
purposes  of  the  meeting  was  to  bring  together  the  various  organizations  and  agencies 
that  have  been  working  independently  on  computer  simulation  models  and  develop  a 
dialogue  among  researchers.  This  objective  was  certainly  obtained. 

LCDR  Kelleher  made  the  point  that  he  considered  himself  a  user  for  the  modelling 
effort.  He  felt  that  combat  simulation  models  are  very  much  a  research  tool  in  addition 
to  their  other  uses.  He  suggested  that  combat  models  could  be  used  to  guide  and 
structure  research  efforts  in  the  future.  He  also  questioned  whether  or  not  we  had  fully 
utilized  the  data  that  is  currently  available.  Maybe  we  need  to  have  a  major  effort  to 
organize  and  make  available  the  existing  human  performance  data  before  we  go  out 
and  collect  moro  data. 

For  detailed  information  regarding  the  presentations  on  the  individual  models  you 
should  pick  up  a  copy  of  the  meeting  proceedings.  We  will,  however,  make  some  very 
general  comments  about  some  of  the  generic  comments  that  were  made  by  the 
speakers. 

Dr  Toms  talked  about  Janus  and  suggested  four  essential  items  for  a  gcod  model. 

Openness  *  full  disclosure  of  the  models  structure  and  content  -  good 
documentation. 

Usefulness  •  The  model  should  be  used  by  individuals  other  than  the 
developer.  It  should  not  be  a  cleaver  laboratory  game. 

Limitations  -  The  limitations  of  the  model  should  be  cieariy  spoiled  out  and 
made  available  to  the  users. 

Validation  *  The  model  should  reflect  what  really  goes  on  in  the  real  world. 

Dr.  Toms  indicated  that  Janus  had  been  changed  over  to  a  distributed  data  processing 
architecture  to  enhance  processing  speed  and  allow  the  running  of  the  model  in 
remote  locations.  Dr.  Toms  reported  that  Janus  included  some  basic  human 
performance  information,  but  that  he  considered  the  lack  of  this  type  of  information  one 
of  the  biggest  short-faJis  in  the  model. 


Mr  Anno  described  the  mutidisciplinary  development  of  Crew  !il  and  how  it  was  a 
continuation  of  the  IDP  work  done  for  the  Defense  Nuclear  Agency.  This  program  like 
many  others  has  used  symptomology  descriptions  to  tie  stress  variables  to 
performance. 
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The  Crew  III  model  is  now  being  used  in  Janus  to  handle  some  of  the  human  \ 

performance  information. 

Dr.  Terhune  talked  about  the  SEES  model  which  is  a  modified  version  of  Janus  that 
was  developed  for  the  Office  of  Security  Evaluations.  It  is  unique  in  its  ability  to  handle 
combat  simulation  in  an  urban  type  environment.  Its  primary  purpose  is  to  model  the 
problem  of  armed  intrusion  against  a  secure  site.  Dr.  Terhune  felt  one  of  the  main 
reasons  for  their  success  has  been  the  close  working  relationship  they  have  had  with 
the  security  guard  users.  They  have  been  intimately  involved  from  the  start. 

Major  Anderson  is  a  user  of  computer  models.  He  manages  the  Tactical  Warfare 
Simulation  (TWSEAS)  unit  at  Camp  Pendleton.  His  system,  like  the  others  presented, 
includes  limited  human  performance  information.  TWSEAS  is  used  for  staff  training 
and  as  such  needs  to  be  as  realistic  as  possible.  Maj.  Anderson  stressed,  however, 
that  the  human  performance  inputs  did  not  have  to  be  perfect,  an  approximation  of  the 
human  element  would  be  better  than  what  he  currently  has. 

Dr.  Klopdc  described  the  AURA  (Army  Resiliency  Analysis)  model.  Unlike  the  other 
models,  AURA  is  a  one  sided  model  that  looks  at  the  functioning  of  a  unit  over  time 
including  times  following  hostile  attack.  AURA  is  designed  to  be  a  framework  into 
which  existing  models  can  be  incorporated.  Dr.  Klopdc  referred  to  AURA  as  a 
methodology  rather  than  a  model.  One  point  that  Dr.  Klopdc  made  that  needs  to  be 
emphasized  is  that  by  not  considering  a  given  variable  in  a  model  does  not  mean  that 
you  have  not  included  its  effect.  It  just  means  you  have  either  consdousiy  or  ( 

unconsciously  assigned  it  a  value  of  one. 

Dr.  Yencha  and  Dr.  Kirk  spoke  on  the  NURA  model  which  is  the  Navy's  version  of 
AURA.  The  model  is  primarily  designed  for  assessing  the  impact  of  chemical  attacks 
on  naval  vessels.  They  are  looking  for  good  human  performance  information  for  their 
model,  more  spedfically,  they  are  looking  for  information  on  the  affects  of  MOPP  gear 
(chemical  warfare  protective  dothing)  on  performance. 

Dr.  Laugher/  devoted  most  of  his  time  to  "task  network  modelling"  which  is  the 
structural  technique  used  in  the  MICRO  SAINT  software.  Dr.  Laughery  feels  that  this 
software  can  act  as  the  bridge  between  human  performance  modelling  and  the 
combat  simulation  model.  MICRO  SAINT  is  a  commercial  product  that  was  developed 
under  government  contract.  It  has  been  used  extensively  for  modelling  human 
performance,  but  it  is  general  enough  to  be  used  to  build  any  network  simulation.  The 
developers  of  MICRO  SAINT  think  that  it  will  do  for  modelling  what  the  spread  sheet 
programs  did  for  finandal  analysis.  Its  user  friendly  nature  will  eliminate  the  need  for  a 
modelling  spedalist  and  bring  modelling  capability  down  to  the  user  level. 

Mr.  Hawkins  described  the  SHIPDAM  model  which  is  a  modified  version  of  the  ship 
vulnerability  model  that  have  been  developed  at  David  Taylor  Research  Center  over 
the  last  1 5  to  20  years.  Its  a  Monte  Carlo  model  designed  to  handle  probabilistic 
events.  The  model  is  not  yet  complete  or  documented,  but  is  being  used  for  several 
projects.  I 
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Commander  Contreras  discussed  the  R&D  system  and  outlining  the  research  project 
review  process.  He  indicated  that  knowledge  of  this  system  was  important  for  gening 
new  initiatives  such  as  combat  simulation  and  human  performance  modelling  funded. 
He  emphasized  the  importance  of  identifying  the  user  community  early  on  in  the 
development  so  that  a  transition  plan  can  be  put  into  place.  He  closed  his 
presentation  by  fisting  the  four  cnteria  he  uses  in  evaluating  new  programs. 

They  are: 

1 .  A  documented  need  or  requirement  and  an  indication  that  the  researcher 
has  taken  the  time  to  learn  about  and  understand  the  problem. 

2.  A  well  laid-out  plan  with  achievable  goals. 

3.  An  indication  that  the  researcher  is  aware  of  and  using  all  available 
resources:  both  equipment  and  information  resources.  Not  just  in  his 
organization,  but  throughout  the  R&D  community. 

4.  An  understanding  and  support  of  the  R&D  system.  For  a  project  to 
develop  smoothly  the  researcher  has  to  know  the  steps  involved  in  the 
R&D  system. 

Finally,  Commander  Contreras  suggested  that  researchers  working  on  computer 
systems  that  potentially  could  be  used  in  operational  medicine  be  aware  of  DAMSEA 
the  Defense  Medical  Systems  Support  Center.  It  is  the  Department  of  Defense  that 
oversees  the  implementation  of  new  computer  systems.  He  was  not  sure  what  they 
were  doing  in  the  modelling  arena,  but  suggested  that  they  be  contacted. 

In  the  general  discussion  session  Dr.  Alluisi  suggested  that  the  human  performance 
modelling  had  to  be  focused  on  those  tasks  that  make  a  difference  in  the  outcome  of 
combat  engagements.  He  suggested  tnat  we  should  conduct  some  sensitivity  studies 
using  the  combat  simulation  models  to  determine  what  tasks  we  need  to  model.  He 
indicated  that  this  information  was  going  to  be  extremely  important  in  the  evaluation  of 
weapon  systems  and  that  the  science  of  combat  simulation  was  going  to  take  on 
increased  importance  in  the  future  because  it  is  one  of  the  only  ways  you  can 
systematically  evaluate  the  importance  of  various  system  components. 

CONCLUSIONS  AND  RECOMMENDATIONS 

1.  We  really  don't  have  a  good  idea  of  what  human  performance  data  is  available 
for  modelers  and/or  how  useful  it  will  be. 

2.  We  need  a  list  of  problem  areas  from  the  modelers  to  help  focus  the  human 
performance  research  effort. 

3.  There  seems  to  be  two  points  of  view  regarding  how  we  should  attack  the 
modelling  problem:  one  suggest  a  boitoms  up  approach  while  the  other  feels 
an  top  down  approach  is  more  appropriate. 

Bottoms  Up  -  Each  lab  has  its  own  particular  needs  and  as  models  are  built  to 
meet  these  needs,  they  can  be  used  as  building  blocks  to  build  larger  combat 
simulation  models. 
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Top  Down  -  If  we  wait  for  the  development  of  all  of  these  individual  models  we 
will  never  get  tc  the  overall  model  that  will  meet  user  needs.  Lets  get  a  rough 
cut  inode!  up  and  running  and  use  it  to  identify  information  that  is  needed.  Let 
the  large  overall  model  drive  the  research  effort. 

4.  Hardware  no  longer  appears  to  be  a  constraint.  By  using  distributed  data 
processing  along  with  32  bit  intelligent  terminals  modelers  seem  to  be  able  to 
do  just  about  everything  they  currently  want  to  do.  The  cloak  point  now  appears 
to  be  the  quality  and  quantity  of  human  performance  data  available. 

5.  There  appears  to  be  a  need  to  bring  in  funding  from  a  number  of  different 
sourcss  rather  than  relying  solely  on  the  Medical  R&D  Command. 

6.  It  was  suggested  that  we  use  a  matrix  of  independent  and  dependent  variables 
to  relate  the  impact  of  various  stressors  to  various  performance  variables.  The 
relationships  could  be  developed  from  the  scientific  literature  and  specifically 
designed  studios.  There  seems  to  be  some  concern  as  to  whether  such  a 
matrix  could  be  translated  into  combat  performance. 

7.  There  appears  to  be  a  need  for  some  sort  of  clearing-house  for  the  exchange  of 
information  regarding  the  modelling  effort.  It  was  suggested  that  an  electronic 
network  be  set  up  that  includes  bulletin  boards  and  electronic  mail  for  the 
dissemination  of  information  and  ideas. 

8.  It  was  suggested  that  a  directory  of  modelers  be  developed  and  that  it  include 
the  electronic  addresses  for  those  on  the  ARPA  Net. 

9.  Several  investigators  felt  that  we  need  to  confine,  at  least  Initially,  the  human 
oerformance  modelling  effort  to  the  small  combat  unit  rather  than  **ying  to 
introduce  human  performance  data  at  the  Division  or  Brigade  level. 

1 0.  There  appears  to  be  a  need  to  get  some  type  of  human  performance 
information  in  the  existing  models  right  now.  We  can  refine  the  development 
after  we  get  something  out  there  operating. 

11.  A  publication  needs  to  be  developed  that  reviews  the  human  performance 
literature  amt  evaluates  the  models  that  are  currently  available.  Something 
similar  to  what  was  done  by  LLNL  for  the  combat  simulation  models. 

RECOMMENDATIONS  /  SUGGESTIONS 

1.  Within  the  US  Navy,  a  combat  simulation  integration  review  function  is  needed 
to  provide  specifications  and  guidance  regarding  the  existing  Navy  modelling 
efforts.  This  function  is  needed  so  that  greater  utility  for  existing  models  can  be 
generated.  It  would  also  allow  for  greater  integration  of  existing  models. 
Currently,  there  are  many  different  machines  and  programs  pjnning  models 
which  cannot  be  easily  joined  together  if  needed.  A  Modelling  oversight  group 
could  insure  that  new  models  conform  to  criteria  and  standards  which  will  allow 


them  to  be  integrated  in  the  future  or  at  least  be  ‘modular  and  transportable"  to 
other  systems/modeis. 

2.  A  Handbook  for  Combat  Simulation  Model  Development  from  a 

multidisciplinary  point  of  view  could  be  very  valuable  in  banding  together 
professionals  from  the  OR,  Physical  Sciences,  Behavioral  Sciences,  and 
Engineering  Communities.  Lawrence  Livermore  National  Laboratory  and  BDM 
have  developed  a  straw-man  table  of  contents  and  a  suggested  author  list  of 
over  30  individuals  to  contribute  to  this  effort  if  sufficient  funding  from  tne  joint 
services  is  obtained. 
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